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
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: cygwin Release process
Date: Tue, 28 Jan 2003 11:02:12 -0500
Message-ID: <7BFCE5F1EF28D64198522688F5449D5AD63B7F@xchangeserver2.storigen.com>
From: "Scott Prive" <Scott DOT Prive AT storigen DOT com>
To: <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Monday, January 27, 2003 6:08 PM
> To: cygwin AT cygwin DOT com
> Subject: Re: cygwin Release process
> 
> 
> On Mon, Jan 27, 2003 at 04:54:25PM -0500, Scott Prive wrote:
> >William,
> >
> >The "ntsec" problem by all accounts was a one-time switch 
> that burned a
> >lot of people.  It seems like a great feature (not 
> completely using it
> >myself), and when I upgraded to it I had NO idea of the impending
> >change.  I should have known better than to perform blind upgrades.
> >
> >I've been using Cywin for maybe 3 years (?) now and that's the only
> >major problem I ever had.  It's STILL not resolved, and I do not have
> >time to attempt correcting it since I have required level of
> >functionality.
> >
> >I'd love to see a release process something like Redhat's or 
> Debian's.
> >But that's not enough -- someone has to maintain it.  As a FORMER ;-)
> >Debian user I can say there are some downsides to too much process...
> >like a "stable" tag that's so old almost no one runs 100% from that
> >branch.
> 
> Ok, that's three people complaining about the ntsec change.  Don't you
> see some faulty reasoning here?  How long do you suppose CYGWIN=ntsec
> existed?  It was around for years.  Lots of people used it.  There was
> no way to anticipate that it would cause problems for some people.

I tried to use my experience to bring William around to your point of view. Because William is concerned about future upgrades, I presented some scenarios for guarding against upgrades. 

I presume you're using Cygwin in a development context -- where it's good if you have more eyeballs testing the current code. I'll go out on a limb and assume William used Cygwin in a production environment -- where the opposite is true. You stay on something you understand, and if you don't knowingly apply major upgrades.
> 
> If we had made the decision to turn CYGWIN=ntsec on in the next major
> "stable" release, then all of horrendous problems that were suffered
> (which, AFAIK, are "solved" these days by saying CYGWIN=nontsec) would
> still have manifested.
> 
> The change *was* announced.  The functionality *was* 
> previously tested.

I don't disagree that the change was "announced". In hindsight, I see it was. Arthur Dent got an announcement before his home was demolished for a bypass (apologies to those who don't get the HHGTTG reference). :-)

To this day, it's still not on the Cygwin.com home page under "What's New". I don't doubt it is mentioned under a particular Release announcement. For better or worse, people in the Windows space wouldn't look there anyways. They wouldn't proactively subscribe to a mailing list and look for problem reports. What many users would assume is a setup utility provides a mechanism for a packager to provide critical warnings that must be acknowledged.  

I can't offer that improvement as a patch -- the best I can do is stay out of the way by assuming responsibility for my own upgrade testing. But it would be nice :-)

I'd like to end this thread with the following comment:

The hours I lost on my ntsec upgrade (and my botched attempts to fix it which probably made it worse) are *insignificant* to the hours of productivity I GAINED by having a mostly-complete GNU environment under Windows. 

Cygwin saved me from a complete rewrite task, of scripts which always assumed Linux. I can't understate how much I gained here. You made the `almost impossible', possible. Thank you (everyone).


> This is not an argument for a stable release.  On the 
> contrary, it's an
> argument for quick corrective releases to fix the problem.
> 
> You make a good point about the old, stable release.  That's 
> one of the
> drawbacks of such a plan.  What about errata?  Are errata going to be
> supplied for the stable release?  Who is going to decide when to make
> a new release?  Is there going to be a voting process?  Who gets to
> vote?  Who gets to arbitrate disputes?
> 
> Debian has a structure for this kind of thing.  So does Red 
> Hat.  I don't
> see any evidence that the Cygwin community has the type of committment
> required for this kind of activity and, I, certainly don't want to be
> worrying about stuff like this.  It requires someone with 
> both the desire
> and organizational skills to pull it together.  The effort to do this
> can't be trivialized.

Agreed.
> 
> I will happily provide the disk space for this but I am not 
> going to be
> changing the way I release the packages I provide.  If 
> someone wants to
> take my packages, decide if they are "experimental" or 
> "stable", and put
> them into a different release framework then more power to 
> them.  Seriously.
> I'll applaud and commend their efforts.
> 
> cgf
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/