[Debian] [neilm@debian.org: Bits from the Release Team - minutes
(pt 1), retrospective, time based freezes and more!]
Ola Lundqvist
opal at debian.org
Thu Jun 30 07:56:48 EDT 2011
Hi OpenVZ people
Next planned freeze date for Debian is June 2012.
Quote from below:
"
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
team.
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.
"
// Ola
----- Forwarded message from Neil McGovern <neilm at debian.org> -----
Envelope-to: ola at inguza.com
Delivery-date: Tue, 28 Jun 2011 20:51:22 +0200
Old-Return-Path: <neilm at debian.org>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on liszt.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-15.6 required=4.0 tests=FOURLA,LDOSUBSCRIBER,
LDO_WHITELIST,MURPHY_DRUGS_REL8,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2,
PGPSIGNATURE autolearn=failed version=3.2.5
X-Virus-Scanned: at lists.debian.org with policy bank moderated
X-Amavis-Spam-Status: No, score=-9.58 tagged_above=-10000 required=5.3
tests=[FOURLA=0.1, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02,
MURPHY_WRONG_WORD1=0.1, MURPHY_WRONG_WORD2=0.2, PGPSIGNATURE=-5]
autolearn=ham
X-policyd-weight: using cached result; rate: -5
X-Greylist: delayed 955 seconds by postgrey-1.31 at liszt; Tue, 28 Jun 2011
18:50:16 UTC
From: Neil McGovern <neilm at debian.org>
To: debian-devel-announce at lists.debian.org
Subject: Bits from the Release Team - minutes (pt 1), retrospective, time
based freezes and more!
Mail-Followup-To: debian-devel-announce at lists.debian.org
X-Debian-Message: Signature check passed for Debian member
X-Rc-Virus: 2007-09-13_01
X-Rc-Spam: 2008-11-04_01
Resent-Message-ID: <QPx21fmq2SO.A.m8B.5JiCOB at liszt>
Resent-From: debian-devel-announce at lists.debian.org
X-Mailing-List: <debian-devel-announce at lists.debian.org> archive/latest/1392
List-Id: <debian-devel-announce.lists.debian.org>
List-Post: <mailto:debian-devel-announce at lists.debian.org>
List-Help: <mailto:debian-devel-announce-request at lists.debian.org?subject=help>
List-Subscribe:
<mailto:debian-devel-announce-request at lists.debian.org?subject=subscribe
>
List-Unsubscribe:
<mailto:debian-devel-announce-request at lists.debian.org?subject=unsubscri
be>
Resent-Sender: debian-devel-announce-request at lists.debian.org
Resent-Date: Tue, 28 Jun 2011 18:50:33 +0000 (UTC)
X-Spam-Score: -2.6 (--)
X-Spamcheck-provider: Checked for spam by inguza.net, postmaster at inguza.net
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.
[SPRINT:WIKI]
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
requests.
* 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 at 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
manner.
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
cycle.
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
team.
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
future.
* 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!
Thanks,
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
----- End forwarded message -----
--
--------------------- Ola Lundqvist ---------------------------
/ opal at debian.org Annebergsslingan 37 \
| ola at inguza.com 654 65 KARLSTAD |
| http://inguza.com/ +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
More information about the Debian
mailing list