This is the mail archive of the cygwin@cygwin.com 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: Cygwin Release process


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.



Here are some suggestions for you William:
1) maintain an internal mirror. Mirroring is very very easy to set up, and you will save your company money by eliminating random bandwidth spikes every time someone upgrades.

2) Make it EASY for your users to use your mirror (see step 3)

3) In the setup.exe GUI, you can manually add in a custom mirror. Find out if you can "preload" your mirror into the GUI, and remove "standard" mirrors. You may need to rebuild setup.exe; I'm not certain.

4) Make it more difficult for users to NOT use your mirror. If you're evil. >:-)

5) If you're running internal software/testsuites on top of Cygwin, you can build a table of version numbers you expect, and what you see on the system. You can automate the building of this table so it is not a hassle every time you "approve" upgrade snapshots. If you think some users will install from the net anyways -- this will save you some debugging/triage time.


disclaimer: I do *not* know what the current capabilities of setup.exe are. You might find discussion along these lines in the archives.

Hope this helps!

Scott





 



> -----Original Message-----
> From: William A. Hoffman [mailto:billlist@nycap.rr.com]
> Sent: Monday, January 27, 2003 3:24 PM
> To: Max Bowsher; cygwin@cygwin.com
> Subject: Re: Cygwin Release process
> 
> 
> Well, if I am the only person with this opinion, then you are right.
> I should stop complaining and burn a CD.   However, I suspect 
> that I am
> not alone in wanting a more stable cygwin.    It will be hard 
> to prove my
> case, as the folks that read this list and post to it, tend to
> be more developer oriented, and are more interested in not missing
> out on the latest features than having a stable platform.
> 
> There must be some reason that RedHat, Debian and all the major linux 
> distributions have releases.   
> 
> I belive that if this were setup, and download stats were 
> created, it would
> be come the most common type of download for cygwin. 
> 
> 
> -Bill
> 
> 
> 
> At 08:07 PM 1/27/2003 +0000, Max Bowsher wrote:
> 
> >If this is not good enough for you, then *just burn a CD*. 
> There is no need
> >to force this artificial 'release' policy on the Cygwin project.
> >
> >
> >Max.
> 
> 
> 
> --
> 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/


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