Re: status of jackd? (bug #318098)
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
Reply to: