bits from the Debian Etch release team

Posted by tadelste on Jan 3, 2006 2:17 PM EDT
Mailing list; By Andreas Barth
Mail this story
Print this story

Happy New Year to all of you. New Year in the western world is the typical point in time to take a look backward and forward to see what happened and what one expects to happen next year. Also, we're almost in the middle between release of sarge and release of etch, another good reason to look both ways. :)



Hi,



We have sent out many release updates during the first months of last year, until we released sarge r0 on 6th of June.

More or less at the same time, we published a proposed set of guidelines for the architectures for the next stable release etch. After some hard discussion, we managed to get a list that was agreed on by most of Debian's developers.[1] The re-qualifications of architectures has happened by now[2], the architectures that didn't qualify have chances to re-qualify every two months. For the release team, this whole discussion helped already a lot, because it makes more obvious who is responsible for what, and it helped to weed out easy resolvable issues that are bad for the release of etch.

Now, let's look forward what we expect to see in 2006: We expect to release etch as planned in beginning of December 2006.[3]

Our time line still is:

N-117 Mon 30 Jul 06: freeze essential toolchain, kernels N-110 Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N Mon 4 Dec 06: release [1.5 months for the general freeze]

The good news is that we are on track to reach this goal.=20

However, we need to start *now* to give the RC-bug count some more attention. This means also that we're going to start again an everlasting BSP: For RC-bugs, you can upload 0-days NMUs for RC-bugs open for more than one week. However, you are still required to notify the maintainer via BTS before uploading. And of course, you need to take care of anything you broke by your NMU.

Also it is critical that NMU patches to source should be as non-disruptive as possible. Do not do housekeeping tasks, do not change the name of modules or files, do not move directories; in general, do not fix things which are not broken. Keep the patch as small as possible. If things both= er you aesthetically, talk to the Debian maintainer, talk to the upstream maintainer, or submit a bug. However, aesthetic changes must not be made in a non-maintainer upload.

And please remember the Hippocratic Oath: "Above all, do no harm." It is better to leave a package with an open grave bug than applying a non-functional patch, or one that hides the bug instead of resolving it.=20

Please see the developers reference for more details [4], and expect another mail soon that tells more about NMU rules.

Looking at the installer, there has been huge progress. Also, a new d-i RC has already been published. We definitely trust the installer team to be ready in time.

There have been some changes to our toolchain, and the toolchain seems to be quite stable by now. There are still some discussions about integration of e.g. multiarch, but it is almost too late for it right now.

Looking at our release targets published back in October[3], we had: - gcc 3.3 -> 4.0 toolchain transition - xfree86 -> xorg transition these two are done - amd64 as an official arch (and the mirror split as a pre-condition for that) this still needs to happen - sorting out docs-in-main vs. the DFSG has happened partially - our biggest issue is still the GFDL-situation. If we look at our release planning, we need to start aggressively removing GFDL-only-documentation beginning of March, unless the license issues are resolved before. - sorting out non-free firmware also some work needs to be done here - or did changes in upstream resolve that mostly for us? - secure apt secure apt is now part of testing. However, we need to do something for key management etc - so some small issues need to be resolved.

So much for now. We wish you a Happy New Year, and let's release etch together beginning of December 06.

Cheers, --=20 Andi Debian Release Team

[1] http://release.debian.org/etch_arch_policy.html [2] http://lists.debian.org/debian-devel-announce/2005/12/msg00013.html [3] http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html [4] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu





  Nav
» Read more about: Story Type: News Story

« Return to the newswire homepage

Subject Topic Starter Replies Views Last Post
It would help to add "etch" in the title amosshapira 0 1,328 Jan 3, 2006 4:52 PM

You cannot post until you login.