Re: Bits (Nybbles?) from the Vancouver release team meeting
-----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-----
Reply to: