Re: Bits (Nybbles?) from the Vancouver release team meeting
Aurélien Jarno <aurelien@aurel32.net> 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
Reply to: