Mail Archives: cygwin/2003/01/28/11:03:36
> -----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/
- Raw text -