Re: Bits (Nybbles?) from the Vancouver release team meeting
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
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: