On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > >Once this happens, >the testing-security configuration should itself be completed for all >architectures in quick succession, with the result that testing-security >and testing-proposed-updates will be fully operational in the space of >two weeks. Cool. It's good to see progress on this. [snip] >Note that this plan makes no changes to the set of supported release >architectures for sarge, but will take effect for testing and unstable >immediately after sarge's release with the result that testing will >contain a greatly reduced set of architectures, according to the >following objective criteria: > >- it must first be part of (or at the very least, meet the criteria for) > scc.debian.org (see below) > >- the release architecture must be publicly available to buy new > >- the release architecture must have N+1 buildds where N is the number > required to keep up with the volume of uploaded packages > >- the value of N above must not be > 2 > >- the release architecture must have successfully compiled 98% of the > archive's source (excluding architecture-specific packages) > >- the release architecture must have a working, tested installer > >- the Security Team must be willing to provide long-term support for > the architecture > >- the Debian System Administrators (DSA) must be willing to support > debian.org machine(s) of that architecture > >- 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 > >- there must be a developer-accessible debian.org machine for the > architecture. > >We project that applying these rules for etch will reduce the set of >candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 >and amd64 -- which will be added after sarge's release when mirror space >is freed up by moving the other architectures to scc.debian.org). >This will drastically reduce the architecture coordination required in >testing, giving us a more limber release process and (it is hoped) a >much shorter release cycle on the order of 12-18 months. When you say "N+1" buildds for a release architecture, do you mean _exactly_ N+1, or _at least_ N+1? Also, a common complaint I've heard recently is that several of the SCC architecture buildd problems were being caused by lack of time. Not machines, not offered effort, but lack of time to do buildd setup/maintenance work by central buildd admins. Note: I'm NOT attributing this to malice or incompetence - people need to sleep and have some semblance of a life outside Debian, after all! m68k has shown that a larger team of buildd admins and machines can work effectively, allowing the least powerful of our architectures to keep up admirably well in recent months. Is the plan for etch to still continue to run with centrally-controlled buildds, or will it be opened up? -- Steve McIntyre, Cambridge, UK. steve@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Attachment:
signature.asc
Description: Digital signature