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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]