[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

- 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: