Right now, we have the problem that an upload of a
> previously compiled source package that’s “totally unimportant” will be
> sorted before all source packages in state “uncompiled”.
Only if we also get a waiver that allows testing to go out-of-sync for these
arches. Otherwise, no thanks.
For release architectures built by the the debian.org build services I
agree that out of date packages should continue to be prioritised. If
due to short term conditions a release architecture is behind on
building then it's usually* more important to keep packages up to date
so they don't block testing transitions than it is to attempt to build
packages the architecture has never built before.
If a release architecture is getting behind on building on a long term
basis then IMO either more buildd hardware should be obtained or the
port should lose it's release status.
But that isn't what we are talking about here, we are talking about an
architecture that was kicked out of testing and kicked out of the
official archive years ago, degraded to an almost unusuable state and is
now attempting to become usable again. For them it's probablly far more
important to build as many "important but not yet built" pckages as
possible than it is to make sure every package they have built is up to
date.
* Though there are corner cases where a new package is actually pretty
important because some other package has been updated to have a
dependency on it.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52629e9d.5030...@p10link.net
