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 -- <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