-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This really sounds a good step. Just one small question, AFAIK package building of softwares on the other obscure platforms has helped raise a lot of hidden bugs. Will that continue ? Will that continue on scc.debian.org?
Regards, Ritesh On Monday 14 Mar 2005 10:15 am, you 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 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. > > 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. > > 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. > > 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. > > 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 > > 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) > > - the architecture must be able to run a buildd 24/7 sustained > (without crashing) > > - the architecture must have an actual, running, working buildd > > - 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) > > - binaries for the proposed architecture must have been built and signed > by official Debian developers > > - the architecture must have successfully compiled 50% of the archive's > source (excluding architecture-specific packages) > > - 5 developers who will use or work on the port must send in > signed requests for its addition > > - the port must demonstrate that they have at least 50 users > > 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. > > 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. > > 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. > > Cheers, - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC "Stealing logic from one person is plagiarism, stealing from many is research". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCNb9j4Rhi6gTxMLwRAu4qAJ94EasGCbG3gHCM2WcoUCQ/ZuY1tgCfRYh/ BHNfJEk88AnAURu8Of+zcWY= =5O+C -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
