Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 01:14:47AM -0800, Steve Langasek wrote:
> On Mon, Mar 14, 2005 at 09:09:09AM +0100, Adrian von Bidder wrote:
> > On Monday 14 March 2005 05.45, Steve Langasek wrote:
> > > Architectures that are no longer being considered for stable releases
> > > are not going to be left out in the cold. The SCC infrastructure is
> > > intended as a long-term option for these other architectures, and the
> > > ftpmasters also intend to provide porter teams with the option of
> > > releasing periodic (or not-so-periodic) per-architecture snapshots of
> > > unstable.
>
> > [I'm a pure x86 user atm, so if this is a non-issue, I'll gladly be
> > educated]
>
> > Why only unstable? In other words: will it be possible for scc arches to
> > have a testing distribution? Obviously, this testing/arch will not
> > influence the release candidate arch testing, but will allow real releases
> > of scc-arches if a RM/release team steps up.
>
> (A popular question...)
>
> 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.
Ideally, all-source-packages-in-svn or whatever and
source-only-full-autobuilds would help greatly with this. Allowing to do a
branch of the repo to upload to the per-arch archive, and have the fix
automatically picked up by the next unstable release.
> 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.
Friendly,
Sven Luther
Reply to: