Message-Id: <200410011009.i91A9Btv031657@delorie.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To: <cygwin AT cygwin DOT com>
Subject: RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Date: Fri, 1 Oct 2004 05:08:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200410010531.i915VL1a014777@a.mail.sonic.net>

> I would like to request that this policy be reversed -- that 
> there be a version number for the entire Cygwin release.  
> Every O/S and application I've used had a release number for 
> the whole thing; Cygwin should as well.
> 
> 
> I would especially like to request that there be a "stable"
> distribution.
> 
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 
> David
> 
> 
> 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.

Yikes, prepare yourself for one heck of a tantrum from certain regular(s) on
the list!  But tantrums aside, I can tell you pretty much for a fact that
this isn't going to happen unless you do it all yourself, almost certainly
as a project unconnected with cygwin proper.  You'd have to at a minimum:

1.  Develop and run apropriate integration tests, a herculean task in and of
itself, especially considering there is nothing of this nature in place now
for the entire project (though the cygwin DLL and many apps of course have
'make test's, but it sounds like that would not be sufficient for your very
high standards).  You *might* get *some* support from "the maintainers" on
this, but you'd certainly be doing 99.44% of the heavy lifting.
2.  Maintain the tested binaries in a cvs repository, so you could tag them
for particular "cygwin releases".  This would be the easy part, but you'll
be setting up, hosting, and maintaining this repository yourself,
guaranteed.
3.  Develop and maintain an installer package for the whole bajillion
megabytes of cygwin+everything that runs on cygwin.  You could probably
cobble together some combination of a single-file installer ala InnoSetup
and the cygwin setup program + your own setup.ini.  Again, you'll get pretty
much zero help here.
4.  You'll have to come up with a versioning scheme that minimizes confusion
between the cygwin version and your distro's version.  You'd probably want
to call it something like "David's Cygwin Distro Version X.XX"  instead of
"Cygwin X.X.X", because the latter is pretty much just wrong.

I'm sure that if you were to do all this, you could probably have a nice
little cottage industry burning and selling Cygwin distros on CD/DVD.  I
personally don't use cygwin this way, as don't a lot of other people.  I use
whatever's newest unless forced to do otherwise (i.e. a bug is found), and I
have no need for the bulk of the multitude of cygwin packages.

I'd do one of three things if I were you:

1.  Roll up your sleeves, get to work, and let the list know when you're
done.  "The maintainers" (yes, I'm looking at you Chris) will at best see
this as a threat to their little fifedom, and the only "help" you'll get
will be in the form of snide comments and passive-aggression.  Those who
aren't openly hostile to your idea will likey rather work on other things.
2.  Work on part #1 above, but intended as a pre-latest-release screen for
normal packages.  Again, that'd be a massive task, and the individual
package maintainers are probably not going to be very interested if they'd
have to do any work beyond running a script.
3.  Abandon all hope of anything like this happening.  Testing is the
bastard child of software (especially open source), and integration testing
is the bastard child of testing.  Nobody is going to volunteer to do this
regardless of how many people express their opinions on the matter.  "Does
it run?  Ship it!" ain't just for commercial software.

I don't want to discourage you here, what you suggest as I say would have
value to many people.  But again, you'd have to be the one to do it, with
little cooperation and/or help from anybody else.  I wish you well.

-- 
Gary R. Van Sickle
 

--
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/