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