As you will have noticed, we have recently had a point release of
Squeeze. This means that it’s well and truly the time to start on the
next release: Wheezy!
The first thing we would like to do is to consider how the previous
release went. We’d like to know what went well, what went badly, and
what to improve for the next release.
Once again, we will use firstname.lastname@example.org and welcome all
comments before 11th April.
Time based freezes
We’re aware that there is an outstanding discussion to be had about time
based freezes (note: _not_ time based releases).
The beginning of a release cycle seems the ideal time for that
discussion and we hope to be in a position to start it after processing
the results of the retrospective.
As mentioned in our last mail [DDA:Done], we would appreciate
transitions which have the potential to cause significant disruption to
the archive for any length of time being coordinated with us before they
As we are at the beginning of the wheezy cycle, there are a number of
changes which have been pending for some time as they were unable to be
considered during the squeeze freeze and the period leading up to it.
The combination of toolchain changes and some larger transitions which
have become entangled are at times making the day-to-day work of
updating packages in unstable more complicated than we would prefer and
an overview of upcoming changes allows us to better manage those issues.
As a first step towards establishing release goals for wheezy, we will
be reviewing each of the goals which we had for squeeze [RDO:SGoals] to
see which have been achieved and which may no longer be relevant for
If you are listed as the proponent for a goal in the above list, please
feel free to provide a status update on progress towards completing it
and whether you believe it is relevant for the wheezy cycle. You can
also e-mail us to propose a new goal, including a description of the
goal and an indication of how progress on the issues may be tracked
(e.g. a pointer to a set of appropriate user-tagged bugs).
In some cases in previous cycles release goals have become “orphaned”,
for instance as a result of the original proponent either being
unavailable to work on them or losing interest. To try and avoid such
issues occurring for wheezy, we are considering requesting that each
goal have a nominated “shepherd” (or shepherds) who will monitor
progress towards the goal and provide regular status updates on that
progress (even if it’s “same as last time”).
We’re also after new goals! I know that expressions of interest in
multiarch and tdebs have already been indicated, but if you have
something you would want to see happen for Wheezy, please let us know.
The release team itself will be suggesting some as part of the review
We feel it would be useful for the Release Team as a whole to get
together to think about what the plans are for the next release. As
such, we’re planning a sprint to meet in person. Details will follow
once diaries have been able to be synchronised!
0-day NMU policy
For some time now, we have had a perpetual 0-day NMU policy, and some
discussion [LDO:0day] was had a while ago. We feel that this has worked
well for the past five years, and so will be submitting a bug against
dev-ref to make this official.
For avoidance of doubt, this means that RC bugs that are older than one
week that haven’t had maintainer activity on it for a week can be
uploaded to DELAYED/0-day. This means that patches must still make their
way to the BTS, and the usual workflow must still follow. Also, to quote
It is important, though, to never forget that doing a 0-day NMU is a
bit like driving an ambulance: you have the right to go fast when/if
it’s crucial for the person inside to arrive the hospital ASAP…
alive. If you’re carrying a minor injured, or you’re a novel driver,
or it’s raining like hell, you still have the right to go fast, but
it’s maybe not the best thing to do. (a.k.a. “nobody prevents you from
uploading NMUs to DELAYED.)