Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 11:00, Sven Luther wrote:
> On Mon, Mar 14, 2005 at 01:14:47AM -0800, Steve Langasek 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).
I'm only guessing: because keeping those archs in testing didn't work out and
is (broadly) the cause dropping them in the first place?
> > 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 ?
Obviously britney/dak is available from cvs.d.o and meanwhile also as debian
package. So the question for me (administrating two sparc boxes) is why _we_
don't setup our own testing when obviously the ftp-masters and core release
masters are not willing to do the work for us?
My answer is that I don't care enough for tow out of 15 boxes for the hassle,
I will update them to sarge, be grateful for the gracetime given and - iff
nobody steps up to do the necessary porting and security work - donate them
to Debian when etchs release leaves my current nameserver without security
updates.
What would you say, if I asked you to provide security support for sparc
because _I_ need it for my nameservers?
> 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 you have hit the point of this reorganisation head on: the people who
did the work until now, feel that they cannot do the work with the expected
quality _and_ the current number of arches. Thus they make the hard decision
to put down hard, objective and verifyable rules where everyone can decide
whether an arch deserves use of central Debian resources like mirrorspace on
the central network.
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: