[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the Release Team - minutes (pt 1), retrospective, time based freezes and more!

In this update:

* Release Team sprint minutes <SPRINT>
* Squeeze wrap up/retrospective <RETRO>
* Release team membership/workload <MEMBERS>
* Time based freezes <TBF>
* Migrations from unstable to testing <BRITNEY>
* Misc, and what's in the next update <COMINGUP>

Hi all,

I'm fully aware that we're well overdue providing a bits mail from the
Release Team. This is the first of a set to be sent over the coming
weeks, and now with a new format that will hopefully make things easier
to read!

If you've got this far, you'll have noticed the section above. I hope
that this can be used for people to get a quick overview of what is in
each update, and the ability to skip to any relevant section they're
interested in.  Obviously I'd prefer that it was all read and digested
in detail, but I know that everyone is busy, and so would like to make
it as easy as possible to get news across.

Release Team sprint minutes <SPRINT>

For those not aware, the release team recently had a sprint in Antwerp.

I'd like to take this opportunity to thank Inuits for providing the
venue, and the Debian project for travel and accommodation sponsorship.

During the sprint itself, we set up a 'live' minute log [SPRINT:LOG] so
that others could follow along. We also attempted to set up a mumble
server, but it unfortunately didn't work at the time.
Over the next few weeks, I hope to convert this log to a set of mails to
send to DDA with proposals and comments on various issues that were
discussed. As a point of reference, 18 distinct topics were got through,
and 16 of those resolved at the weekend, which shows just how well these
sprints can work.

Squeeze wrap up/retrospective <RETRO>

A large piece of work that I wanted to undertake immediately following
the previous release was a 'retrospective'. I recognise that no matter
how hard we try, we're not perfect, and so this was an opportunity for
people to give their views on how the previous release went.
We collated the responses and want to address the top concerns for the
next release. A table of all comment topics can be found at
[RETRO:DETAIL] for those who are interested, but we tried to group these
into themes.

So, first the good points:
* High Quality Release
  We managed to produce a release to be proud of. We had the quality
  that Debian is famous for. As an example, one user who responded said
  that their wifi card worked with Debian, but it didn't with any other
  distribution that they had tried.
* BTS (tag) handling
  Developers liked the use of the BTS for triaging requests to the
  release team, and to get an overview of potential removals, or states
  of packages.
* Unblock handling
  Generally, people were happy with the amount of time, and the
  flexibility that the release team was able to provide handling unblock
* Communications improved
  There was a feeling that communication in the form of both
  announcements, and personal communication with package maintainers had
  improved significantly over previous years.
* Length of time between releases
  It was made clear that developers were fairly happy with the
  timeliness of the release itself.

Next, the not-so-good points, and what we're doing to fix it:
* DebConf 9 freeze announcement/discussion
  A lot of people commented about the decisions that were made at
  DebConf 9, and the communication of those to the project. We recognise
  that this was a mistake, and shouldn't have happened in the way it
  did. We will ensure that the project as a whole is consulted before
  any major changes are implemented.
* Freeze announcement at DebConf 10.
  Although we did get some comments that there was a lot of clarity
  about the freeze approach, it still took a large number of people by
  surprise. We hope to provide clarity about this with our comments on
  time based freezes: see below!
* Clarity of process/policies
  As a partner to the above comment on unblock handling, there is a
  confusion as to what criteria is being applied at different stages,
  and it was felt that more information on the process and policies that
  the release team uses would be useful. As such, we will document to a
  much greater degree what we're doing than we have done before.  But to
  do this, we'd like to know what format you'd like it in. Would you
  like a glossary and/or an FAQ? Would flowcharts help? As always,
  feedback@release.debian.org is a good email address for ideas.
* Manpower in the Team
  Long term readers of DDA mails may recognise this as a perennial
  problem with all teams. We're all volunteers and no one has as much
  time as they would like to give! See the item below on how we want to
  address this...

Release team membership/workload <MEMBERS>

Three main topic areas came out of the discussion we had during the
sprint, to try and see how the Release Team can cope with the amount of
work we have, and how we can work with the project better.

* The Role of the RM: administrative / co-ordination vs technical
  Many projects have a non-technical focused RM who is in charge of
  simply ensuring that the release happens from a 'project management'
  point of view.  They should be in charge of making sure that the
  project as a whole knows what's going on, and that everything is
  tracked and comes together at the right time. This is something we
  tried over the last release, and hope to continue in a more formal
  As such, I will be taking on this side of the Release Manager role,
  and Adam will continue with the technical running of the work. We may
  hop between roles a little, but we hope to keep this focus.

* Better tracking / distribution of ongoing work
* More involvement of / delegation to resources outside of the team
* Better tools to manage tracking of unblocks, review of larger patches
  The above items are related to reducing the amount of work that the
  release team have to handle. We'll be looking at tools that are
  available to help provide clarity to the project, ease review of
  packages and see how we can get the developer base as a whole involved
  more in the release process.

* Team membership changes
  We've had a check of those involved in the release team, and have the
  following two changes:
  - We would like to thank Pierre Habouzit for his hard work, but due to
    other commitments he has chosen to step down.
  - We would like to welcome Niels Thykier to the team.

If you're interested in joining the team, the best way is to get
involved!  We'll be getting some documentation together of easy tasks
that any developer can do to help the release.

Time based freezes <TBF>

For past releases, we mainly looked at the number of RC bugs and
opinions of core teams to pick a freeze date. While this worked out
quite well, it was not easy for maintainers to make plans during each
After some discussion at the sprint, we have looked again at the concept
of having a time based freeze. I'd like to thank the DPL for progressing
a consensus on debian-devel on a way forward for this proposal.
The release team would like to support the idea of a time based freeze.

Its main advantage seems to be the clarity that people will get knowing
when we will freeze. For this reason, we need to pick a date. This is
one that not everyone will be happy with, and caused quite a bit of
discussion. However, we had to make a decision, and have picked on June
2012 as the current proposed freeze date for the next release.

Good plans are never perfect though. "Time-based freezes" have
downsides. There is the possibility that we may not be in a good
position to freeze when the date approaches. Please keep in mind that
releasing is shared task, not purely the responsibility of the release

If this doesn't work for whatever reason, we'll look at this again, but
for the moment we'd like to try this for the next release. To avoid
surprises, we'll send reminders about the coming freeze in (almost)
every bits mail. We'll also start making use of BTS tags before the
freeze date, and encouraging people to squash RC bugs before we freeze.

Note the above: we hope to FREEZE IN JUNE 2012.

Migrations from unstable to testing <BRITNEY>

A decade ago, Anthony Towns wrote what became "britney", the script that
is still used today (with a variety of patches, bug fixes and hopefully
not too many new bugs) to migrate packages from unstable to testing.
While watching all the migrations, and the level of brokenness that
we've come to expect in unstable following a release, we felt rather sad
that we weren't able to add to this level of uncertainty.
Thus, we feel it is now the right time in the cycle to move to a new
tool.  Thus, we will move to britney2 which has been under trial for
some time. We hope that nothing will break and that testing will remain
a suite, but the only way to be certain is to try it out, so please bear
with us!

Misc, and what's in the next update <COMINGUP>

Two smaller items also discussed:
* Private IRC channel
  Until recently, we have operated a private IRC channel for the release
  team members. We feel that this is inappropriate to continue as a
  permanent fixture, so we will use #debian-release for all chat in
* ries
  For anyone who wants to look at release.debian.org, and ftp-master, we
  remind developers that ries.debian.org carries a (near) live mirror,
  and can be used to run queries on the project databases. This is
  particularly useful if you would like to see why a transition isn't
  completing, for example.

Coming up in the next release update:
* Release Goals
* Arch requalification
* 0-day NMU policy
* CUT/Rolling
* Package removal process
* And more!

Neil, on behalf of the release team.

[SPRINT:WIKI] http://wiki.debian.org/Sprints/2011/Release
[SPRINT:LOG] http://titanpad.com/ep/pad/view/N9IpRX1eSP/8YdwjhVhVm
[RETRO:DETAIL] http://wiki.debian.org/Sprints/2011/Release/Detail
<weasel> dpkg: shut up
<dpkg> No, I won't, and you can't make me. :P
<weasel> hah.  _I_ can

Attachment: pgpEnI6Dv5rng.pgp
Description: PGP signature

Reply to: