Re: Vancouver meeting - clarifications
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
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: