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,
> [email protected] 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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
