En réponse à Michael Banck <mbanck@gmx.net>:
> On Wed, Feb 26, 2003 at 09:26:51PM +0100, Jérôme Marant wrote:
> > I personaly think of a problem related to architecture
> > synchronization, i.e. a given package can't enter testing if it
> has
> > not been built on all architectures. There are more and more
> > architectures so it takes more and more time for a package to
> enter
> > testing.
>
> A package rests in unstable for ten days anyway. I think the
> autobuilders are working well enough so that most packages will be
> compiled on all arches by that time and that issue won't hold up
> testing
> *in general* (of course, there might and will be exceptions to the
> rule)
It depends on the number of dependencies. Of course, a package with
few dependencies has few problems.
> IMHO the bigger problem are buggy packages and packages waiting on
> dependencies to get into testing as well (either because those
> dependencies are buggy, or because they are uninstallable and the
> maintainer did not fix it yet. D'oh, they're buggy anyway :) )
Yes, but they may be buggy on some architectures only for some
reason. They have to be fixed but they are installable on some
other architecures.
> What we could learn about this glibc debac^W"issue" is perhaps opening
> up unstable *for base packages* as soon as they are frozen (and I mean
> *frozen* this time...), so that by the time of the release, they might
> actually be at least half done to enter testing. That way, testing
> might
> not be held up that much as soon as the new symlinks are in place.
We could also decide consider testing dependencies rather than
unstable dependencies, and perhaps rebuild packages for testing.
> When we said we'd had to wait how testing behaves after the first
> release, nobody expected the span^Wglibc thingy. So perhaps we'll have
> to wait one more time to see how britney really performs in the wild.
Do we require all the time the latest version of glibc?
--
Jérôme Marant <jerome@marant.org>
<jerome.marant@free.fr>
http://marant.org