Re: Bits (Nybbles?) from the Vancouver release team meeting

[Aurélien Jarno]

Frank Küster a écrit :
I think Sven was talking about *his* proposal for an alternative
handling of SCC architectures, giving them a chance to be released.
Oops sorry. I am not really against, but we should before try to address 
the real problems.

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.
Maybe it is really a problem of manpower. In that case, why help has 
been refused to help w-b as Ingo already said?

They may be a manpower problem, but I have never seen a call for help. 
Somebody that want to help don't know where to ask.

I have recently asked on IRC if I can help to set up the buildd for 
testing, the answer was something like (my English is not enough good so 
that I can remember the English sentence): "You can pray for neuro's 
moving to get smoothly".

- 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.
Why they don't ask for help?
- 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!).
Which mean much more work. If the security infrastructure is set up, one 
package can get built on all architectures automatically.

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.
I don't consider amd64 as a secondary arch, and even less as a slow 
arch. This is really different than let say arm or m68k.

Cheers,
Aurelien
--
  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED]         | [EMAIL PROTECTED]
   `-    people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]