Building tier-2 against testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tuesday 15 March 2005 10:41, Sven Luther wrote:
> 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 ?
Sven, Steve is referring to the first part of his mail, where he says that
building from testing will lose "any of the controls testing is supposed to
provide to protect against uninstallable packages".
> And how do
> you make sure those arches have a stable base to do their daily work on ?
More stable than unstable? As stable as testing? Please explain this to me, I
am little slow in the morning.
> And if testing is not appropriate for them, why don't we drop testing
> altogether ?
Off the top of my head I would say because testing was appropriate for a small
number of arches but didn't appropriately scale for a bigger number of arches
where the probability of breakage on any single one of them approaches one.
Also testing is absolutely needed to be able to properly support stable after
the release: this needs synced arches, else security updates would need to
recompile several different minor diverging versions each time.
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Reply to: