Debian Edu Wheezy (was Re: Bits from the Release Team - minutes (pt 1), retrospective, time based freezes and more!
Hi,
while we're still busy working on Debian Edu Squeeze, others are busy with
Wheezy, the next Debian release. Quoting the mail quoted below (in full):
"However, we had to make a decision, and have picked on June 2012 as the
current proposed freeze date for the next release."
So this is when we should stop developing Debian Edu Wheezy ;-)
cheers,
Holger
On Dienstag, 28. Juni 2011, Neil McGovern wrote:
> 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@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
Reply to: