[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packages directly into stable



-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 28 Jan 1997, Brian C. White wrote:

> sacampbe@mercator.math.uwaterloo.ca wrote:
> 
> > 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/
> 

OK, can I come back with my old proposition?

The purpose is to have 3 main distributions: unstable, frozen and stable.

stable are for the current release, it's there to provided a *stable* 
release for users. Most of the time, developpers will avoid it cause we 
love to live on the edge ;)

frozen are a permanent up-to-come release distribution. It looks mostly 
like the current unstable but are more checked. Package who gone there 
will have all their dependancies resolve are well known to be stable 
(dependancies are checked, it almost install correctly). Their is where 
testers do their work.

unstable are just something between the current unstable and experimental.
New package or new important or critical release (such as glibc6, the new
passwd script or the new realease of X11) that may affect other package must
go there.  That's let developper try some new thing without affecting the 
next distribution.

That's really looks like a pre-release distribution but the main 
difference is in the fact that packages in unstable aren't automaticly 
upgrade to stable. It can stay here until it looks ok to be frozen.

I would add that unstable could now contains non-free packages cause it 
will be really unstable (but more organized than experimental). 
Distributor will be ok to do not distribute them.

just my 2 pennies.

- ---------------------------------------------------------------
 "Computers in the future may weigh no more than 1.5 tons."
                                 -- Popular Mechanics, 1949
 
 measure with micrometer, mark with chalk, cut with axe, 
  then hope like hell...
- ---------------------------------------------------------------
Fabien Ninoles aka le Veneur aka le Corbeau     
E-mail: Ninf01@gel.usherb.ca               
WebPage: http://www-edu.gel.usherb.ca/ninf01 
Finger me for my pgp key (finger ninf01@gel.usherb.ca)
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMu95V1X6fc7jcjhFAQHRLwP+N+Sh+of3lTblFyqDqVBv3Q5LRKZhFDXX
GWjQxk5GFOK5VjPpQCccSuTaiulaw+S8RpklPwCoP6i+J2KwG5iFik/nO+7f33G3
2ziFzokZTzdavE298LFagPDz2e6GOPLa4gx8NsJWpDCGsMn6Yg13wWZAf21Xt9X+
7VfcUmWGJEA=
=q5V3
-----END PGP SIGNATURE-----


--
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: