Re: Woody retrospective and Sarge introspective
Le Wed, Jul 31, 2002 at 02:08:57AM +1000, Anthony Towns écrivait:
> Which adds an extra distribution that has to be:
> * carried on the mirrors (+50%)
> * tracked in the BTS (+75-100%)
> * maintained by each developer (+100%)
> * administered by ftpmaster, etc (+30%)
> * understood by our userbase (+30%)
> * tested (+90%)
Luckily enough, there are similar figures on the other end :
- average size of the hard drive +100%
- average growth of network capacity +x%
- number of debian developers +100%
The ftpmasters can scale by adding more people, maybe some who are
entitled to manage "candidate" specifically.
As for maintainers, the doubling of work is not always self-evident
since people already provide two version of the packages but one in
experimental and one in unstable. Furthermore people already provide
other unstable deb in their homepage. And as I said, not all maintainers
will use the possibility to have 3 versions of their packages. Very
simple packages may well go into candidate directly without having
separate versions for unstable/testing (example: several of my
binary-all perl modules would fit in that category).
Concerning the BTS, I don't see that as a problem. One can filter by
tags if necessary. And having multiple maintainers for big packages will
still be a good solution.
For our userbase, candidate is not difficult to understand in particular
if they already managed to understand testing ! :)
Since candidate would logically be the next stable, it will attract
people who will test it ... some people actually using testing will
probably switch to candidate. Sid users will keep sid as usual.
> etc. The numbers in brackets are an estimate of how much extra work will
> have to be done compared to what's currently done. I don't think what
> you're suggesting is feasible.
Ignore feasibilty for now, do you think it would help us to release more
frequently by effectively having a candidate distribution that would be
always mostly ready ?
> That's quite possibly true -- certainly the archive as it stands doesn't
> handle "large" updates as well as it might. But that's a relatively minor
> problem, IMO. It's certainly too minor to warrant coming anywhere near
I wouldn't call that a minor problem when it involves the update of
hundreds of packages with new (not very well tested) code. By pushing
those in unstable/testing we're effectively making sarge unreleasable
until things settle down (several months imho). And when you have
several large updates like this one which cross in the thime (perl-5.8,
gcc3., xf4.2, kde3, ...), you get many troubles to effectively "freeze"
the distribution ...
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com