On Tue, Aug 09, 2005 at 03:56:21PM -0700, Erik Steffl wrote: > David Nusinow wrote: > >Where would you like us to do our work? This is exactly what unstable is > > errr... where would YOU like to work? In intentionally broken > unstable becuase "it's just unstable"? You surprise me.
No. But this is a recurring theme that happens every time after we release a new stable. It currently goes like this: * Stable releases * Freeze is lifted * The new and shiny updates that people wanted to bring in for a few months now but that they held back because we were in freeze is uploaded all at once. * All kinds of funny and unpredictable things happen. X breaks. After the woody freeze, I remember PAM breaking because of a slight typo by the maintainer somewhere. The combination of the new libfoo and the half-upgraded libbar transition happens to work when black magic and the phase of the moon cooperate, but break libbaz and libquux on the off chance that they sometimes do not work correctly. Preferably in horrible ways. * After a few months, the worst transitions and fuckups are over resp. get fixed. People start talking of doing the next freeze again. * This next freeze takes a while (last time, we had a period of approximately one year in which at least _some_ packages were in a state of freeze). During this period, people start using unstable more often because 'it just works'. Only to be disappionted at things breaking when the freeze is over and when unstable is, well, unstable again. * Complaints like in this thread happen on -devel, because unstable just happened to work for a while, so people have forgotten what unstable is for. I wasn't there for the breakage after potato; but I was there with woody, and we see it again with Sarge now. Unstable is _a_development_system_. The purpose of a development system is to allow it to break without interfering with a users' system. The fact that our development system is out there for everyone to use doesn't matter -- if you'd get access to development versions of Windows or MacOS X (which you probably won't, unless you happen to work at Microsoft or Apple), and it would break down, you'd expect that; you'd file a bug rather than complain how bad Windows or MacOS X is. The same should be true for Debian. Yes, there is experimental, and yes, experimental can help alleviate the problems unstable has. But it cannot completely avoid them; experimental is for stuff that you expect to break, while unstable is for stuff that you don't expect to break. The key word here is 'expect'; having unstable only for stuff that will not break would be great, but is simply impossible -- you can only be sure whether it will or will not break by allowing people to try it. And let's be fair about this; unstable/testing has a *lot* more users than experimental. > >*for*. It lets us break things while they're in development in order to > >push the distro as a whole forward. No one says that you have to be running > > isn't that what experimental is for? No. Summarizing the above, experimental is there for people to break on purpose, while unstable is there for people to break by accident. Since a lot of changes are happening right now, a lot of accidents happen as well -- which results in an overall reduction in quality of the system. There's nothing we can do to fix that -- other than by expelling everyone who ever makes even the slightest mistake. But I don't like the sound of that... > >the s00p3r 133t newest version of everything on your system at all times. > > no but I want to. Because non-1337 stuff is usally several years old > (not at the moment but it's getting old fast) and not suitable for > desktop usage (in general) I hear that argument a lot, and it makes me wonder. If three-year-old software is not suitable for desktop usage in general, then what did you do three years ago? Use pen and paper? If you really want the s00p3 l33t newest version of everything, then you need to accept that it comes with a lot of bugs. That's where the term 'bleeding edge' comes from. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
