This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution


> -----Original Message-----
> From: cygwin-owner On Behalf Of David Christensen
> Sent: 01 October 2004 06:31

> cygwin@OHFORCRYINGOUTLOUD.XXX:

  http://cygwin.com/acronyms#PCYMTNQREAIYR, then please don't go and manually
enter any either!

> Per the Cygwin FAQ (http://cygwin.com/faq.html):
> 
> 	"If you are looking for the version number for the whole Cygwin
> release, there is none. Each package in the Cygwin release has its own
> version. The packages in Cygwin are continually improving, 
> thanks to the
> efforts of net volunteers who maintain the Cygwin binary ports. Each
> package has its own version numbers and its own release process. "
> 
> 
> I would like to request that this policy be reversed -- that 
> there be a version number for the entire Cygwin release.  

  Well, you haven't explained how you would like this to be achived.  As far as I
can see, the only two ways would be a) Have an overall version number that is
bumped every time any package changes at all, or b) Forbid package maintainers
from making releases directly, but instead accumulate all the new releases they
come up with and roll them all up into a new "entire Cygwin release" at arbitrary
intervals, at which time a new version number is assigned to the overall bundle.
Is there another option I've overlooked?

> Every O/S and  application
> I've used had a release number for the whole thing; Cygwin should as
> well.

  As has been pointed out before, this is simply not remotely true.  Every O/S
you've used has a release number that applies only to the core O/S without any
relevance to the applications, and there are always many versions of applications
per version of each O/S.  So you could achive the same goal by simply choosing the
version number of the dll as your "entire Cygwin release" version number.

> I would especially like to request that there be a "stable"
> distribution.

  There's absolutely no reason on earth why you shouldn't go ahead and assemble a
"stable" distribution for yourself.

> Why?  Because:
> 
> 1.  I use Cygwin for all sorts of stuff, including mission-critical
> backup chores.  I was recently bitten by the cron-2.6.2 EOF issue, as
> were others.  This represents real damages that people are 
> suffering by
> using Cygwin.  This is bad for the open-source movement.

  What "cron-2.6.2 EOF issue"?  I couldn't find any reference to a cygwin version
of cron earlier than 3.0.something.  However, on the assumption that you mean
rsync, the problem presumably happened when you upgraded to the latest version,
yes?  And you think this is the cygwin project's or rsync maintainer's fault?

  No, this is entirely your own fault for following bad practice.  Why on earth
did you go replacing a known-good version of a mission-critical app in a
production environment with an unknown and untested version?  Have you ever heard
of 'change control management'?  If it was already working as desired, and there
wasn't some critical bug or security fix or vital new feature you needed, it was
irresponsible and reckless of you to go and change the installed version.  The
urge to always have the very latest versions of everything is completely
pointless: there's no need for it and it imposes risk to your project without any
clear benefit in exchange.  When you went to upgrade that already-working-package,
you were on a hiding to nothing.

  It also has nothing to do with the open-source movement.  Nobody installs the
latest and newest version of Windows onto a production server the second it hits
the streets, precisely because the latest'n'greatest version of _any_ software is
also _always_ the least reliable and stable, and everybody knows it.  Why do you
think so many major corporations still use Nt4Sp6 for all their working servers?
Because it's a known quantity, stable and well understood and refined and debugged
over many years.  You don't go and install the latest beta longhorn release on an
operationally vital machine, not if you value the continuity of your business you
don't.

> 2.  This is not the first time I've experienced this meta-problem.  It
> indicates a lack of integration testing of Cygwin as a whole.  This is
> also bad.
> 
> 3.  I would like to be able to burn Cygwin X.Y.Z onto a CD or DVD for
> myself and for others.  This is good.
> 
> 4.  I develop software and would like to be able to tell 
> people "it runs on Cygwin X.Y.Z".  This is also good.

  Right, this is a reasonable suggestion: that you want Cygwin to become a
distribution, like one of the major Linux distros, with a tested and integrated
set of packages.  This begins to answer my earlier question: I assume that you
want co-ordinated releases at infrequent intervals rather than ad-hoc releases by
maintainers whenever they have new versions.

  Unfortunately, it's a lot of work.  This is why corporations like Red Hat and
SuSE and Debian and whoever can charge money for the work they do in packaging,
integrating, testing and certifying distros.  So if you wanted to set up a company
in the business of making Cygwin distros, you could do so, and then you would
stand in the same relation to Cygwin as Red Hat, Debian, et al. do in relation to
the Linux kernel.

  However, it would be a _vast_ amount of work to assemble a distro based around
Cygwin starting from scratch, similarly to how it has involved a vast amount of
man-years and financial resources to develop the commercial Linux distros to the
levels of testing, stability, integration and reliability they are achieving these
days.  Nobody's going to put that amount of effort into something unless a) they
really badly want it for themselves, or b) someone else pays them to do so.

  So there's nothing to stop you doing your own testing and establishing a set of
package versions and a dll version that you can guarantee to work well together,
and if you did that you could undoubtedly sell it and become the first Cygwin
distro.  Or you can take option b), and pay someone to do this work for you:  I'm
sure Red Hat would still be glad to discuss terms for Cygwin support contracts.

> I hereby request that everybody who reads this message reply 
> and express
> their opinion so that the Cygwin release maintainers will 
> know what the community wants.

  I'm perfectly happy with the current system.  I myself maintain an approved
distribution for internal use here at my work.  I've taken a much more simplistic
approach to it though, because I don't have vast resources to throw at it.
Basically, I've been keeping an eye on the mailing list, and when it seemed to me
that the dll was going through a fairly stable patch, I rsync'd a local mirror.
And that's it.  If any packages turn out to have major bugs or security holes, and
even then _only_ if those problems impact on the users who I have to support, then
I'll update them.  If something new is released, and there is a demand for it from
my users, then I'll add it.  But anything that works, I'm not going to fix.

> p.s.  I hereby volunteer my time to work on implementing my request.
> However, be warned that I have very high standards and, 
> especially as a
> volunteer, I will not tolerate my time being wasted.

  If you want me to "express my opinion" on this paragraph, we'll have to TITTL.
I'm tempted to offer my opinion whether it's wanted or not, but it's not going to
have much to do with Cygwin

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]