On Wednesday 29 July 2009, Meike Reichle wrote: > The Debian project has decided to adopt a new policy of time-based > development freezes for future releases, on a two-year cycle. I am fine with that, at least I think we should give a chance to this method. They are some concerns about bad synchronisation with some upstream projects, but I am sure we can find some arrangements. > Freezes > will from now on happen in the December of every odd year, which means > that releases will from now on happen sometime in the first half of every > even year. To that effect the next freeze will happen in December > 2009, with a release expected in spring 2010. I have a lot more problems with that. If this short release cycle had been announced a few weeks after the release of Lenny, it would have been fine. With such a late announce, a lot of developers and teams have already made their schedule and plans based on a roughly 2 year release for Squeeze, and it is really frustrating to have cut them down. I am also really concerned by the state of the release team. Sid is opened again for 5 months, and the freeze will happen in 5 months, so we are just in the middle. If we look a bit what happens on the release team since the release of Lenny, it has simply been absent. A lot of mails on debian-release about hints or binNMU are ignored, mails about transitions are answered very late. The recent MySQL transition is just an example. Last but not least, the transitions are not really managed and take a lot of time (for example QEMU is blocked out of testing for 2 months due to the bluez transition). That's why I would like to ask a single question to the release team: What are your plans to ensure the development process of Squeeze is not slowed down by migration and transitions issues? Or said otherwise how the release team is going to ensure fast reaction to the requests on the mailing list and short transitions (more one week than two months)? The three new release assistants seems to be a first answer to that, but I really doubt it is enough. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: Digital signature