Re: packages directly into stable
sacampbe@mercator.math.uwaterloo.ca wrote:
(Hey! Another Waterloo person! <gives the secret handshake>)
> Lars Wirzenius:
> > sacampbe@mercator.math.uwaterloo.ca:
> > > All package upgrades, except security fixes, must reside in unstable
> > > for one week before being placed into stable.
> >
> > This doesn't help, if no-one actually tests the package. At the
> > moment, we have no way to know that.
>
> Perhaps I should elaborate. We need to set up a system that
> minimizes the chance of buggy packages getting into stable.
> Although by no means foolproof, it
> is much better than the current system and quite simple. I'm sure
> it would catch most problems in the required packages since many people
> like to live on the bleeding edge.
Unfortunately, it won't work this way. Because the "unstable" system
can be significantly different from the "stable" version, a package
that works on one may not work on the other because of bugs, features,
and slight changes in dependant packages.
Dependancies also prevent a direct move from "unstable" to "stable".
The most common case of this is "libc". There have been about half
a dozen packages that got placed into "stable" even though they
depended upon a version of libc that was only in "unstable". For
release 1.2, I think fixing stable packages has actually caused more
problems than it solved.
> What else would you have people do? :
> Trust maintainers: current system. See the problems it's caused.
>
> Require that a certain number of people install the package and
> send in replies stating the package is ok (for them). Has possibilities,
> but relying on testers like this isn't good. Too many would let others
> respond.
>
> Hmm, I can't really come up with any other good ideas. The suggestion
> is certainly better than the current system and can't hurt.
What I would propose it to make sure the release is stable enough and
the next release is close enough that there is almost never a case for
something to become fixed in the stable release. An occasional exception
can be handled, but as a general case the current policy is killing us.
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
Give others some insight into YOUR pages! http://www.verisim.com/insite/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: