[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:
> Hello, world,
> | - 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. :)
> We want that all unstable packages are directly built under normal
> circumstances and that in the even of a buildd going down the arch does
> not suffer noticably.  The long periods of trying to get some RC-bugfix
> in while some arch has a backlog should disappear with etch.

You mysteriously dropped the N should be <= 1 proposal here, which is the one
which generated outcry from the slower arches. Why ? 

> | - 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.

And what happens if the DSA are not willing to support the architecture but
someone else is ? Do this someone else get invited in the DSA team ? Or as a
DSA assistent for that architecture, with limited or no power on the other
machines of the project ?

> | - 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, but it is an all-powerful veto-right, which should be assorted with
adequate counter-limitations to ensure someone will not abuse it in the

> Having said this, this all doesn't exclude the possibility for a
> non-release arch to have some "testing" which can be (mostly) in sync with
> the release architectures testing - just that if it breaks, the release
> team is not forced anymore to hold the strings together.  For example,
> the amd64-people are doing something like that right now.

Yes, but the proposal doesn't invite for this to happen, nor shows clearly
that this is a wanted thing. 

> I hope that this mail is able to shed some light onto these issues. Please
> accept my apologies for the missing information in the first mail.

Thanks for the clarifications,


Sven Luther

Reply to: