[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: