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
future.
> 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,
Friendly,
Sven Luther
Reply to: