As you've probably read by now, the Installer Team has announced  the
availability of the second beta for the Squeeze installer. Testing of
these images is highly encouraged.
Following the plan outlined in the previous release update , we are
now in deep freeze, which means that we'll only be migrating to testing
packages that fix RC bugs.
Please don't send other types of unblock requests, unless you are
certain that our time hearing your reasons will be time well spent;
thanks in advance. (If you sent a request some time ago, please
follow-up to the original mail as soon as possible, in case it has been
Remaining RC bugs
Firstly, I'd like to thank all those DDs who have been squashing bugs,
fixing translations and writing release notes. It's thanks to you that
we are in the position we are in at the moment.
As hinted in the previous release update, now is the time to decide
exactly what is going in to squeeze and what isn't. Here's what we're
going to propose regarding the remaining RC bugs.
We'll be working against the list of RC bugs affecting Squeeze that are
not fixed in unstable:
Members of the Release Team will be considering bugs in that list, in
Which mean, respectively, that a fix can be deferred to r1 or later (a
squeeze-ignore tag will be set), or the package will be removed prior to
the release (if having to delay Squeeze hurts more than the package
being absent from the release), or that it must absolutely be fixed. We
will look at various metrics when deciding this, but in the end it's a
judgement call. Please bear in mind that we all want the best, most up
to date, and most stable release possible, and sometimes we will have to
make decisions we don't want to take.
When we add an "is-blocker" tag, we'll send a mail to -devel as well,
though it is our hope that there won't be any. Also, if you disagree
with any of the labellings, please send your rationale to -release. We
will try and comment with the reasoning for the classification, but I'm
fairly keen to avoid being drawn in to extended arguments along the
lines of "exactly what is a high popcon count?" etc.
Nevertheless, fixes for "can-defer" or "will-remove" bugs will be *very*
welcome. In fact, you are very much encouraged to go over the list
yourself, and apply *your* judgement as to what bugs should be blockers,
and then fix them, or convince somebody to fix them. We'll be doing our
best to ensure all uploaded fixes make it into Squeeze r0.
As always, you need not send unblock requests for RC bug fixes, but
you're welcome to if you prefer to receive an explicit ACK that it's
Finally, if you can't fix RC bugs, maybe you can help with the Release
Notes. A call for help was sent back in November , and this is the
last opportunity to provide any patches before the coordinators set a
freeze date for translators to work.
We will shortly be attempting to formulate a date for release with all
the teams. This date will be firm, but not impossible to move if
something really critical pops up (eg: a needed machine crashing etc).
This will be based on metrics, as always, of getting to 0 RC bugs. We'll
communicate this in our next release update.
There has been a bit of discussion about what the "theme" for Squeeze
should be. We will accept "Space Fun" as the theme for Squeeze as it has
been decided by the Desktop Team. Besides, it is far too late in the
cycle (as you can see!) to rework or create a new theme from scratch.
Further discussion for Wheezy can begin after Squeeze release.
Once we've released
I'd quite like to get a project plan/timeline/milestone document in
place to help us plan the Wheezy release. This will help make sure we
don't miss anything, and discussions which need to happen early in the
cycle can happen in plenty of time.
Of course, we can also do with more volunteers. A call for help will be
sent out after the release to try and increase capacity from interested
parties. So watch this space!