William A. Hoffman wrote: > What I am suggesting is taking the same approach as Debian. > Each package in Debian is in one of these states: > Stable, Testing, or Unstable. > > Stable packages - should work.
We have this. Its called [curr] > Testing packages - working on becoming the next stable version > Unstable packages - all other packages, might be working towards > Testing status. We don't differentiate these. We call such packages [test]. > At some point in time, all Stable packages are collected up, and > a Stable Debian release is made. Only security patches can be > applied to the packages that make up a stable release. This requires a large amount of organization. It's not going to happen. It's also unneccessary since [curr] should be stable anyway, at any point. > I think it is very important to have an entire cygwin that is stable. > As it is now, when you run Setup, you have no idea what you will get. > It is likely to be very different than the machine you did last week. Cygwin works on a basis of continual upgrades. If this worries you, then burn a CD, or create a network share. Instant frozen version. > Almost every time I update cygwin I get some sort of unexpected > problem. > Last time it was the ntsecurity stuff, that is now fixed, but for a > week or two, > the "Stable" cygwin, did not work on networked XP machines. Just > this > last time, I got a copy of tclsh83.exe installed into /usr/bin that > does > not follow the naming convention, (it should be cygtclsh83) This > caused > problems on my machine. It's obvious (in hindsight) that the ntsec change should have been done much slower, or not at all. Things like this haven't happened often, and I imagine that the lesson of the ntsec change will be remembered. > If I run Setup today, I may get some other problem. You might. But its very unlikely. There are very many people running a continuously updated Cygwin. Even if a problem arises, you can always roll back a version. > There really needs to be a stable snapshot of the entire cygwin. Do you volunteer to maintain such a thing? If not, who do you expect to do it? > It would be a known quantity, with expected problems. > It is much like working with CVS. > You have periodic releases of the software that are put on a CVS > release branch, the branch only gets serious errors fixes, but no > new development is done on the branch. Brave folks and developers, > that need the current development, can > cvs update from the main tree. And many small projects use CVS, but don't do branches, because there are not enough developers to support seperate streams of development. > I realize that software changes quickly, but there are folks that > just want to use cygwin. We still have machines that ran setup a > year ago, and for what they need to do, cygwin works fine. I really > do not think it would be that much to ask for a stable snapshot of > the all the packages in cygwin three times a year. Only serious > bugs and security problems can be patched on > the packages in the release of cygwin. > > "Moving to Fast" is exactly the problem. You can not have stable > and fast moving development at the same time. Stable means working and un-changed. > > Lets say I have ten computers that I want to install cygwin on. If > I go around > to each computer and run setup, by the time I am done, I could have > 10 different installations of cygwin, and each computer may run > slightly different. I do not > see how that is stable. > > stable: > - Resistant to change of position or condition; not easily moved or > disturbed: a house built on stable ground; a stable platform. > - Not subject to sudden or extreme change or fluctuation: a stable > economy; a stable currency. You made your point several paragraphs ago. Now you're ranting. As I said above: You want a snapshot? Make one. Download, burn to CD or put on internal network. Done. > As a whole cygwin is a very un-stable platform, because each of the > packages that make up cygwin, are in constant motion. My experience does not support this opinion. 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/
