Hello As most people in this threas have expressed lot of bad feelings about this. I must tell that I think this proposal is a good step toward quicker releases etc. With the clarifications (see the new thread) I must say that this is a very sane proposal. Some people tend to think the worst of everything. If you look at this proposal as a proposal and with the intention to make things working in a good way, I think this proposal is one of the best ones in a very long time. As stated below, I will happily second this proposal, with some minor exceptions, listed below. On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > Hello all, > > As promised earlier on -project[0], after the release team/ftpmaster > team meeting-of-minds last weekend, we have some news to share with the > rest of the project. > > First, the news for sarge. As mentioned in the last release team > update[1], deploying the testing-security queues has been held up > pending some infrastructure enhancements, without which > ftp-master.debian.org cannot handle the load of the added wanna-build > queues for testing-security. This week, Andreas Barth and Ryan Murray > have been applying the finishing touches to allow the needed upgrade of > ftp-master.debian.org's openssh to a version that supports connection > caching, which is needed before the current ftp-master host will scale > to handle the addition of testing-security queues. 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. This is really great news! > This means that we are now (at long last) in the final stretch for > sarge's release, and we will be freezing soon once we know that d-i RC3 > is golden. While this does not yet give us a timeline with fixed dates > for the freeze and the release, this is noteworthy enough in itself that > we wanted to share the news immediately. > > This also means that it's time again to ask maintainers to cut back on > uploads of new upstream versions of software, *particularly* of > libraries. This hasn't been mentioned in recent release team updates, > since it's not very realistic to insist on no new upstream versions for > six months without a complete freeze; but as we get close to the freeze > it's particularly important to limit churn of library packages, since > they tend to delay packages that depend on them -- as has bitten us > several times recently. If you believe a library needs updating for > sarge, please talk to the release team (debian-release@lists.debian.org) > before uploading. > > > The much larger consequence of this meeting, however, has been the > crafting of a prospective release plan for etch. The release team and > the ftpmasters are mutually agreed that it is not sustainable to > continue making coordinated releases for as many architectures as sarge > currently contains, let alone for as many new proposed architectures as > are waiting in the wings. 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. It's also not clear how much benefit there is from doing stable > releases for all of these architectures, because they aren't necessarily > useful to the communities surrounding those ports. As this is a fact it is not much to say about it. More manpower may help this but apparently there are not enough people. > Therefore, we're planning on not releasing most of the minor architectures > starting with etch. They will be released with sarge, with all that > implies (including security support until sarge is archived), but they > would no longer be included in testing. > > This is a very large step, and while we've discussed it fairly thoroughly > and think we've got most of the bugs worked out, we'd appreciate hearing > any comments you might have. > > This change has superseded the previous SCC (second-class citizen > architecture) plan that had already been proposed to reduce the amount of > data Debian mirrors are required to carry; prior to the release of sarge, > the ftpmasters plan to bring scc.debian.org on-line and begin making > non-release-candidate architectures available from scc.debian.org for > unstable. As proposed before I think ports.debian.org is a better name. :) > 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 Sane, especially with the comment in the clarification mail. > - the release architecture must have N+1 buildds where N is the number > required to keep up with the volume of uploaded packages Sane. > - the value of N above must not be > 2 Testing related. I do not really understand why this is a problem but somebody may be able to tell. > - the release architecture must have successfully compiled 98% of the > archive's source (excluding architecture-specific packages) Well as expressed in the clarification mail this is a bit hard limit. I think something around 95 to 98 would be better. Don't let this be a really hard limit. > - the release architecture must have a working, tested installer Obviously. > - the Security Team must be willing to provide long-term support for > the architecture Obviously. And I assume that if someone is willing to help that will be accepted. > - the Debian System Administrators (DSA) must be willing to support > debian.org machine(s) of that architecture I assume people can help with this too, or? > - 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 As it always has been. I think it is a bit tough and maybe it should be discussed on debian-devel first. Just my opinion. > - there must be a developer-accessible debian.org machine for the > architecture. Obviously. > 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). I'm missing sparc here, but that is only me... But even if that one is included the drop will probably help some. > 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. We can always hope for that. It would certainly be easier to test to build packages on all supported architectures before uploading to unstable with this approach. > Architectures that are no longer being considered for stable releases > are not going to be left out in the cold. The SCC infrastructure is > intended as a long-term option for these other architectures, and the > ftpmasters also intend to provide porter teams with the option of > releasing periodic (or not-so-periodic) per-architecture snapshots of > unstable. Sounds really good. And I assume that if the architecture can show that they fulfill the requirements, it will be included again. > Also, since the original purpose of the SCC proposal was to reduce the size > of the archive that mirrors had to carry, the list of release candidate > architectures will be further split, with only the most popular ones > distributed via ftp.debian.org itself. The criterion for being distributed > from ftp.debian.org (and its mirrors) is roughly: > > - there must be a sufficient user base to justify inclusion on all > mirrors, defined as 10% of downloads over a sampled set of mirrors This as stated before, probably a too tight limit. I think 10% of the downloads if i386 is excluded is a better metric. :) > To be eligible for inclusion in the archive at all, even in the > (unstable-only) SCC archive, ftpmasters have specified the following > architecture requirements: > > - the architecture must be freely usable (i.e., without NDAs) Obviously. > - the architecture must be able to run a buildd 24/7 sustained > (without crashing) Sane. > - the architecture must have an actual, running, working buildd Sane. > - the port must include basic unix functionality, e.g resolving > DNS names and firewalling :) > - binary packages must be built from the unmodified Debian source > (required, among other reasons, for license compliance) This is a bit vauge. Is porting uploads possible? > - binaries for the proposed architecture must have been built and signed > by official Debian developers Sane. > - the architecture must have successfully compiled 50% of the archive's > source (excluding architecture-specific packages) Sane. > - 5 developers who will use or work on the port must send in > signed requests for its addition Sane. > - the port must demonstrate that they have at least 50 users Should be very easy. > These objective requirements would be applied both to the other eight > architectures being released with sarge that are not currently regarded > as candidates for release with etch, and also to any porter requests > asking for new architectures to be added to the archive. With these comments I will happily second this proposal. > This plan has been signed off on by: > > Steve Langasek (Release Manager) > Colin Watson (Release Manager) > Andreas Barth (Release Assistant) > Joey Hess (Release Assistant) > Frank Lichtenheld (Release Assistant) > > James Troup (ftpmaster) > Ryan Murray (ftpmaster) > Anthony Towns (ftpmaster) > > The following people in Debian leadership roles have also expressed their > support: > > Andreas Schuldei (DPL candidate) > Angus Lees (DPL candidate) > Branden Robinson (DPL candidate) > Jonathan Walther (DPL candidate) > > Again, if you've got any questions, comments or concerns, please raise them > on -devel so we can take them into account before putting this plan into > effect. > > > Further plans for etch > ---------------------- > > After the release of sarge, the release team will stop tracking the > day-to-day status of RC bugs in testing for a while. NMUs for broken > packages will be minimal; instead, our RC bug handling will mostly be > limited to the usual aggressive removal of broken packages from testing. > This will also be a key time for the QA team to focus on deeper quality > issues and methods for a change, instead of on individual > release-critical bugs. > > Meanwhile, much of the release team's energy will be focused on > coordinating the many major changes that are sure to hit the archive > shortly after sarge's release. We already know of a number of major > package changes coming up: gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6. > If you are planning any other transitions that will affect a lot of > packages, please let us know in advance. We will need to complete the > larger transitions as fast as possible, to get testing back into a > nearly releasable state quickly again after the release. > > It's also not too early to begin staging complex transitions for etch in > experimental, particularly those transitions that will take a while to > debug. > > Post-sarge, we also know that with the new social contract, all > documentation needs to adhere to the DFSG. The biggest impact of this > change is that documentation that is licensed only under the current > version of the GNU Free Documentation License (GFDL) needs to be made > available under a license that meets the requirements of the DFSG, or > else be moved to non-free. Some maintainers have already opted to move > their GFDL documentation to non-free for sarge, but the vast remainder > will need to be dealt with soon after sarge's release to keep us on > track for etch. This worries me much more than this proposal actually. I think this will take a lot of time. > Otherwise, it's business as usual for the sarge release. Please bear in > mind previous release team updates [1][2] when preparing package uploads > to unstable; and if you have any questions, please ask the release team > before uploading. Best regards, // Ola > Cheers, > -- > Steve Langasek [vorlon@debian.org] > Debian Release Team > > [0] http://lists.debian.org/debian-project/2005/03/msg00015.html > [1] http://lists.debian.org/debian-devel-announce/2005/02/msg00010.html > [2] http://lists.debian.org/debian-devel-announce/2004/11/msg00003.html -- --------------------- Ola Lundqvist --------------------------- / opal@debian.org Annebergsslingan 37 \ | opal@lysator.liu.se 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature