Aurélien Jarno <[EMAIL PROTECTED]> schrieb: > Sven Luther a écrit : >> On Mon, Mar 14, 2005 at 02:38:01PM +0100, Aurélien Jarno wrote: >> >>>Sven Luther a écrit : >>> >>>> - Not having slower arches hold up testing. >>> >>>Slower arches don't hold up testing. Arches with buildd not well managed do. >> Ok, drop this argument, but what do you think of the rest of the >> proposal ? > I totally disagree with it. The current proposal (or even decision?), > is like cutting the leg when only one toe is affected.
I think Sven was talking about *his* proposal for an alternative handling of SCC architectures, giving them a chance to be released. > What about partial mirroring to address space problems? What about a > team for wanna-build so that help and machines are not refused > anymore? What about a team for buildd so that there is always an admin > available at a given time? > > Maybe it doesn't work, but at least we have to try, before dropping > arches. I got the impression that the large number of arches indeed is a problem for the release process. Not because individual arches slow it down, but because it causes a high workload for the d-i team, security team, etc, and these people are often also involved in other RC tasks. Therefore I am inclined to accept that the proposal (or decision, or whatever) that we need to drop some arches from the main release process is not an arbitrary step taken by a mad gang, but actually necessary. There are, however, some things that should be done differently than outlined in the text written at the meeting: - First of all, we should take the details as a starting point for discussion, not as a decision that has made. Nevertheless, we must take into account that there are reasons for it: The people doing the release, ftpmaster, etc. work noticed that they cannot go on like before. - We should definitely make sure that Debian will continue to be a distribution that supports lots of architectures, and that means real support, including releases and security updates. However, release *names* as "Debian etch" might not necessarily support so many arches; the less-known arches might have a different release schedule, and there may be by-port security teams (plus by-port announce lists!). > Because it's clear that SCC arches will be dropped sooner or > later, if they are considered by debian-developers as "secondary > arches". That is a problem. However it seemed that the amd64 people could solve it nevertheless. And I think there can also be technical and/or social mechanisms to deal with that: - The possibility for direct uploads by porters into their arches - For unmaintained packages a policy that allows NMUs that address RC bugs for non-RC arches - If active maintainers refuse to apply patches for SCC arches, asking the TC for a decision should get a usual habit, and for the maintainers it should not mean an insult or whatever (just as currently NMUs, especiall localization NMUs, are standard practice). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
