Re: Bits (Nybbles?) from the Vancouver release team meeting
Steve Langasek <vorlon@debian.org> writes:
> 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);
Why is that a problem?
The only problem mentioned (and nothing has been discussed) is mirror
bandwith/space limitations. If scc is split into a seperate archive
(seperate hostname and all) and is strictly voluntary it in no way
affects the size or mirrors of the main archs. The only thing affected
would be scc.d.o (go buy a bigger disk debian has money) and voluntary
scc mirrors.
I doubt those mirrors that deside to mirror scc.d.o (adding 10G source
+ 10G per arch) mind a few extra G for per arch testing sources. scc
mirrors can be partial and only mirror some archs or only testing or
only unstable. Let the mirror admins decide if they have the space.
> 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.
If scc is on scc.d.o that can be a seperate system from the main
archive. Lots of spare cpu time there to run it's own britney. As for
the RC bugs that indeed is a problem. I guess debbugs can be patched
to have more tags and packages can be tagged 'rc-mipsel' by the porter
team or maintainer. Reportbug could even add the tag automatically
when reporting a RC bug from an scc arch.
> 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.
If porters can do a testing and stable tree on their own (i.e. 2
seperatly managed snapshots) all is fine. But then you have the extra
sources lying around again that you wanted to avoid.
> --
> Steve Langasek
> postmodern programmer
MfG
Goswin
Reply to: