Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 01:21:59AM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 11:00:12AM +0100, Sven Luther wrote:
>
> > > There are a few problems with trying to run testing for architectures
> > > that aren't being kept in sync. First, if they're not being kept in
> > > sync, it increases the number of matching source packages that we need
> > > to keep around (which, as has been discussed, is already a problem);
> > > second, if you want to update using the testing scripts, you either have
> > > to run a separate copy of britney for each arch (time consuming,
> > > resource-intensive) or continue processing it as part of the main
> > > britney run (we already tread the line in terms of how many archs
> > > britney can handle, and using a single britney check for archs that
> > > aren't keeping up doesn't give very good results); and third, if
> > > failures on non-release archs are not release-critical bugs (which
> > > they're not), you don't have any sane measure of bugginess for britney
> > > to use in deciding which packages to keep out.
>
> > What about building the scc (or tier 2 as i would say) arches from testing and
> > not unstable ? this way you would have the main benefit of testing (no RC
> > bugs, no breakage of the day kind of problems). Obviously this means you would
> > need some kind of override for per-arch fixes, but preferably these fixes will
> > be applied twice, once to the per-arch repo, and then to a new unstable upload
> > which fixes the problem. Uploading only to unstable may cause undue delays.
>
> Building against testing instead of against unstable also means you
> don't have any of the controls testing is supposed to provide to protect
> against uninstallable packages: as soon as you build a new library
> package, everything that depends on it is uninstallable.
No, because each arch will have per-arch testing support. It is just a way for
the arches to catch up with testing, and thus being in line for a release, as
when testing gets frozen, those arches will naturally catch up to the frozen
and then released stable version, and be ready for a point release later on.
> This really makes unstable snapshotting, or building stable once it's
> released as Anthony has also suggested in this thread, look like much
> better options than trying to build out of testing.
We all agree that random unstable snapshotting i no good idea, but i disagree
with the stable snapshoting, since this means that the tier-2 arches will only
be able to really start working once stable is released, while at the same
time working for the next stable release, thus introducing a skew of effort.
The proposal i have, altough maybe not perfect, will allow for the arches to
continue working at mostly the same pace as the rest of the project, and thus
not be excluded.
> > > For these reasons, I think the snapshotting approach is a better option,
> > > because it puts the package selection choices directly in the hands of
> > > the porters rather than trying to munge the existing testing scripts
> > > into something that will make reasonable package selections for you.
>
> > So, why don't you do snapshoting for testing ? Do you not think handling all
> > those thousands of packages manually without the automated testing thinhy
> > would be not an over-burden for those guys ?
>
> > You are really just saying that the testing scipts don't scale well, and
> > instead of finding a solution to this, you say let's drop a bunch of architecture,
> > and make it another-one's problem.
>
> I think we should discuss various solutions to address the needs of
> porters involved in non-release archs. I think trying to run a full
> testing infrastructure, or build against testing instead of unstable, is
> unlikely to be a good solution for those porters in practice because of
> some of the issues that I've pointed out.
Could you be more clear about this ? which issues are those ? And how do you
make sure those arches have a stable base to do their daily work on ? And if
testing is not appropriate for them, why don't we drop testing altogether ?
Again this smells at kicking them out and letting them in the cold, altough i
doubt that was your intention.
Friendly,
Sven Luther
Reply to: