In this update: * Release Goals
It’s time for another release update. A couple of days ago, at DebConf
11, I gave a talk entitled ‘Bits from the Release Team’. Slides for this
can be viewed at
http://prezi.com/fb8usf_fn9k8/bits-from-the-release-team/ , or a PDF
version at http://release.debian.org/talks/debconf11-rt.pdf
Additionally, this mail follows up on the previous minutes from our
Release Goals are areas of functionality which developers would like to
see as an aim for the next release. They won’t hold up the release, but
allow the bugs opened for that goal to be severity ‘important’.
Additionally, the Release Team will help track them
Please note: a release goal should be:
* SMART (Specific, measurable, attainable, realistic, timely)
* Affect more than just one set of packages (i.e.: not just a package
* Have an ‘advocate’, who can track and keep status of progress.
We’ve had a look at all the current goals, and the proposed new ones.
Below is a list of goals, and their status. Given the list is rather
long, please have a look at Release Goals on the wiki for details as to
why these are in the following classes, or to find out more details
about them! [GOALS:WIKI]
Completed last release:
– Boot performance
– Package Quality
– Old libraries
– New source package format
Carried forward from last release:
– IPv6 support
– Large File Support
– Getting rid of .la files
New for this release:
– /run support
– v4l v1 removal
– stop using /dev/dsp
More details needed:
Rejected (at the moment) for this release:
– Grub 2 as default bootloader (Not suitable as a release goal)
– Python 2.7 (Not suitable as a release goal)
– build time test suites (missing an advocate)
– run time test suites (missing an advocate)
– FHS 3.0 (missing an advocate and details)
We have recently updated the Arch Requalification table [ARCHQUAL:TABLE]
with the current known status of the architectures. As we may be looking
at introducing new architectures, and indeed partial architectures, it
is important to ensure that our current architectures remain supportable
for the coming release.
We will shortly be mailing the porter lists asking for comments and a
status update, as we suspect that some of the information is currently
0-day NMU policy <0DNMU>
As noted in our previous mail [0DAY:DDA], bug #625449 has been opened
against developers-reference. This now seems to be drawing itself to a
conclusion. We would still welcome use of delayed queues where
appropriate, but this also formalises the policy over the previous few
years which allows DELAYED/0 for uploads fixing only release-critical
bugs older than 7 days, with no maintainer activity on the bug for 7
days and no indication that a fix is in progress.
As mentioned in the slides above, the Release Team welcome any efforts
to improve our release process. We don’t think, however, that the use of
a new suite is the most efficient way of achieving this goal. Certain
aspects of the proposals can improve Debian, and we invite those who are
interested in CUT/Rolling to run the suite to see what improvements
could be made, or to help improve current testing.
As one of the driving factors behind Rolling seems to be the slowing
down of new features in unstable, we would like to make experimental a
lot easier to use and develop with.
Thus, we have been talking to the FTP Masters about how to do this.
These discussions have led to a number of new features, which will be
introduced over this release cycle:
* Ability to move packages with binaries from experimental to unstable
via an archive tool
* Ability to create ephemeral unstable suites for individual developers
to manage transitions, or try new features
* A new mailing list, debian-experimental-changes which will list
changes to the experimental suite. This has been filed as bug #635875,
please follow up there if you’d like to see this!
Package removal process
One of the concerns that has been raised in the past has been the
visibility of package removals from testing. Due to this concern, we
will be shortly implementing a new tool to a) provide visibility of
removals and b) identify packages for removal in a more automated way.
This tool will (eventually) find potential packages for removal, and
will add these to a ‘delayed removal’ list. It will email debian-devel
on a daily basis saying which packages are due to be removed, and why.
This will also happen for packages identified manually. This should
enable a much higher degree of visibility for removals, and we intend to
use this process before the tool is ready to find its own packages.
Note, however it may still be necessary to drop packages from testing on
a temporary basis to handle (for example) transitions. These may be
actioned at short notice.
What’s due in the next update!
* handling of debian-installer uploads
* how official CDs get released
* Documentation, documentation, documentation
* And more…
Neil (RM of the day)