![\"debian.png\"](\"https:\/\/www.zarrelli.org\/blog\/wp-content\/uploads\/2006\/11\/debian.png\")
<\/p>\n<\/p>\n
testing d-i Release Candidate 1 and more release adjustments<\/strong><\/p>\n * To: debian-devel-announce@lists.debian.org Congratulations to the Debian Installer team for publishing their first We have also reviewed our status with respect to the timeline in other Nevertheless, it would not be possible to release etch on the original Call for testing It is our goal to have full security support for testing available shortly The soft freeze continues The release team depends on your cooperation with these guidelines in order Updates to frozen packages Release goals and etch-ignores Remember that other non-RC policy violations, while not covered by the We have also decided to ignore two certain class of bugs for etch that Second, newly-detected RFCs in source packages will also be treated as Please still feel free to fix any etch-ignore bugs for the release. As You can’t have pudding if you don’t eat your meat Summary Please still follow [4]: No new upstream releases and no transitions, The release will probably be delayed by about the same as the full freeze, Cheers, [1] http:\/\/lists.debian.org\/debian-devel-announce\/2006\/11\/msg00003.html testing d-i Release Candidate 1 and more release adjustments * To: debian-devel-announce@lists.debian.org * Subject: testing d-i Release Candidate 1 and more release adjustments * From: Steve Langasek * Date: Thu, 16 Nov 2006 04:57:31 -0800 * Mail-followup-to: debian-devel-announce@lists.debian.org * Message-id: <20061116125731.GA18505@mauritius.dodds.net> * Old-return-path: * User-agent: Mutt\/1.5.13 (2006-08-11) Congratulations to the Debian Installer team for publishing …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16,31],"tags":[98,479,139,126],"class_list":{"0":"post-429","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"hentry","6":"category-debian","7":"category-gnulinux","8":"tag-bug","9":"tag-internet","10":"tag-linux","11":"tag-security","13":"without-featured-image"},"_links":{"self":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/429","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/comments?post=429"}],"version-history":[{"count":0,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/429\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/media?parent=429"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/categories?post=429"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/tags?post=429"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n * Subject: testing d-i Release Candidate 1 and more release adjustments
\n * From: Steve Langasek
\n * Date: Thu, 16 Nov 2006 04:57:31 -0800
\n * Mail-followup-to: debian-devel-announce@lists.debian.org
\n * Message-id: <20061116125731.GA18505@mauritius.dodds.net>
\n * Old-return-path: <\/vorlon>
\n * User-agent: Mutt\/1.5.13 (2006-08-11)<\/p>\n
\nRelease Candidate for Etch!<\/strong>[1] This means it’s time for two things: to
\nask users to begin more extensive testing of Etch as a system, and to
\nrevisit our release schedule to see where we are.<\/p>\n
\nRelease timeline
\n================
\nThe proposed release schedule included an expected date for RC1 in the
\nmiddle of August, which means that – by this measure – we’re three months
\nbehind. The release schedule did include some padding and we can reduce
\nthe time between RC1 and the release, but not by a whole three months –
\nespecially since we (and the kernel team) want to include Linux 2.6.18 for
\nEtch, which will require a second installer release candidate before
\nrelease.<\/p>\n
\nareas. The good news is that overall, Etch is in good shape. New bug
\nreports about release-critical issues are still coming in as expected, but
\nwith recent rounds of bug filing for build failures happening even before
\nthe start of the full freeze, and our better tracking of bugs fixed only in
\nunstable as a result of version-tracking in the BTS, we are confident that
\nthe RC bug graph[2] genuinely shows that we are converging on a release.
\nWe know for sure that release-critical bugs are being fixed faster than
\nthey’re being introduced, which is great news for our users. Good job,
\ndevelopers! Please keep up the great work of helping the release and our
\nusers by fixing release critical bugs and, heck, any other bugs too.<\/p>\n
\ntarget date while also meeting the Debian community’s expectations of
\nquality. We do expect to freeze the full archive soon now that the
\ninstaller RC 1 is out, which means a freeze delay of about one month from
\nthe original projection, and a similar delay for the release.<\/p>\n
\n================
\nWith the installer candidate out and an initial draft of the release notes
\navailable[3], we can use some help now from intrepid users doing upgrade
\ntesting from sarge to etch. While security support for embargoed issues is
\nnot yet available for etch and there are release-critical bugs yet to
\nresolve, we’re happy to remind you that even before the freeze, testing is
\nof very high quality; there will still be changes for bugs, but even before
\nit’s released as stable we are very proud to have you test it with the
\nconfidence that it will be a very usable and high-quality system — just
\nnot quite the perfection we look for in a release. \ud83d\ude09<\/p>\n
\nafter the start of the hard freeze. Until then, we can’t recommend
\nupgrading systems to etch on the public Internet, but we will welcome any
\ntesting help you can provide. Please help us by reporting problems you
\nfind in the upgrade process against the upgrade-reports package, issues you
\nbelieve should be documented in the release notes against the release-notes
\npackage, and bugs found in individual packages after upgrade to those
\npackages.<\/p>\n
\n=========================
\nWe have not yet reached a point where we believe there should be a hard
\nfreeze of updates into etch, but we ask your continued support by avoiding
\nuploads that are likely to introduce regressions or be disruptive to other
\npackages so close before release. Please do not upload new upstream
\nreleases or start library transitions without discussing with the release
\nteam, and please don’t upload changes to unstable that are not meant for
\nEtch. You can always upload such changes to experimental.<\/p>\n
\nto keep the Etch release moving forward at the present pace. If too many
\nnew release-critical bugs are added because maintainers ignore these
\nguidelines, we will have to consider enacting a hard freeze in spite of the
\nbug count — which means more administrative work for the release team, a
\nlonger freeze and a later release. So if you want to see an etch release
\nthis year, please consider the impact that your uploads will have on this
\ntimeline.<\/p>\n
\n==========================
\nWe have previously noted the kinds of fixes that are allowed into Etch for
\npackages that are frozen[4]. Please remember that while the release team
\nwill track the status of packages fixing release critical bugs, if you want
\na frozen package to be updated because of severity: important bugfixes or
\ndocumentation\/l10n changes, it is your responsibility to notify the release
\nteam by sending mail to debian-release@lists.debian.org.<\/p>\n
\n==============================
\nAfter a mailing list discussion about release-criticality and policy, we’ve
\ndecided to include “fixing bashisms” as a release goal. This means that if
\npackages have bugs that render them unusable with other implementations of
\n\/bin\/sh, such as dash, we encourage maintainers to consider NMUing those
\npackages under the same rules that govern release-critical bugfixes.[5]
\nThis does not mean that such bugfixes *are* release-critical (they’re
\nseverity: important unless there is another reason they should be release
\ncritical), so such fixes will be included in Etch on a best-effort basis.<\/p>\n
\nrelease team’s 0-day NMU policy, might still be candidates for NMUs; please
\nsee the Developer’s Reference[6] for recommendations on NMUing.<\/p>\n
\nwould nominally be considered RC. First, packages should not rely on
\nnon-essential packages during postrm\/purge, but bugs about packages that
\nfail to purge when debconf is not installed will be tagged etch-ignore as
\nlong as the package has a correct dependency on debconf otherwise. Failing
\nto purge by calling other, less prevalent non-essential tools will still be
\nRC; please check the postrms of your packages, don’t wait for someone to
\nfile a bug!<\/p>\n
\netch-ignore, though they will certainly be release-critical for etch+1.<\/p>\n
\nwith release goals, we will accept these fixes on a best-effort basis. You
\nwill need to prod the release team to allow the package into Etch for such
\nfixes if the package is frozen, but we are happy to allow these fixes in.<\/p>\n
\n=================================================
\nIf you managed to read so far: Congratulations! That means you get to be
\none of the lucky first 10 people to know the codename for the next Debian release: it will be called Lenny<\/strong>.<\/p>\n
\n=======
\nPlease test the debian-installer Release Candidate 1.<\/p>\n
\nunless explicitly agreed by the release team. Also, please don’t upload
\nchanges that are not meant for Etch to unstable. You can of course use
\nexperimental for any changes, however experimental they are. Please keep
\nthat policy for unstable until after the release of Etch, even during hard
\nfreeze.<\/p>\n
\nthat is a month. We hope to still release in December 2006.<\/p>\n
\n—
\nSteve Langasek Give me a lever long enough and a Free OS
\nDebian Release Team to set it on, and I can move the world.
\nvorlon@debian.org http:\/\/www.debian.org\/<\/p>\n
\n[2] http:\/\/bugs.debian.org\/release-critical\/
\n[3] http:\/\/www.debian.org\/releases\/etch\/releasenotes
\n[4] http:\/\/lists.debian.org\/debian-devel-announce\/2006\/11\/msg00000.html
\n[5] http:\/\/lists.debian.org\/debian-devel-announce\/2006\/07\/msg00005.html
\n[6] http:\/\/www.debian.org\/doc\/developers-reference\/ch-pkgs.en.html#s-nmu
\n<\/vorlon><\/p>\n","protected":false},"excerpt":{"rendered":"