On Tue, Mar 15, 2005 at 08:58:44AM +0100, Andreas Barth wrote: > As Steve wrote > | The reality is that keeping eleven > | architectures in a releasable state has been a major source of work for > | the release team, the d-i team, and the kernel team over the past year; > | not to mention the time spent by the DSA/buildd admins and the security > | team. > Considering the experience of the release team, the number of different > architectures were _one_ part responsible for release delays - not the only > one, and the others need also to be solved. Could you share a little bit more your experience? You say it is part responsible for release delays, could you tell us why?
> | - the release architecture must have N+1 buildds where N is the number > | required to keep up with the volume of uploaded packages > The reason for this proposal should be instantly clear to everyone who > ever suffered from buildd backlogs. :) Which means a lot more buildd. Does the ftpmasters will accept them? > | - the Security Team must be willing to provide long-term support for > | the architecture > If not, we can't release with that arch. I think this is also quite > obvious. Of course, one way to get the security team to provide support > might be to help them. > > | - the Debian System Administrators (DSA) must be willing to support > | debian.org machine(s) of that architecture > | - there must be a developer-accessible debian.org machine for the > | architecture. > Well, the second point is - I hope - obvious why we want this. This first > one is just a conclusion of the second. If they don't want, in why a developer-accessible debian.org machine supported by the arch porter team is a problem? > | - the Release Team can veto the architecture's inclusion if they have > | overwhelming concerns regarding the architecture's impact on the > | release quality or the release cycle length > This is just more or less an emergency-exit: If we consider an architecture > really unfit for release, we can use our veto. This is one of the things I > hope will never happen. Yes, as again, so that empowers don't loose too much power... > For example, the more architectures are included the longer the migration > testing script takes. We are already at the limit currently (and also > have out-of-memory issues from time to time). For example, currently we > restrict the number of some hints to only 5 per day to keep up the > scripts. If there isn't enough memory, what about adding some, or changing the machine doing that job? Not let's drop archs, that's easier... -- .''`. 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]
