On 05/01/2011 08:02 PM, Lucas Nussbaum wrote:
There are "compromise" solutions, too:
[Plan C -- freeze rolling before forking frozen:]
- do plan A.
- But When the release team decides to do a general freeze,
rolling is frozen for a few months to maximize user testing and
developer attention. After two to four months, 'frozen' is forked
from 'rolling', and the normal 'rolling' process resumes.
That still means starting the dev cycle with something that's not the just
released stable. It looks like a problem, to me.
I also think that trying to reduce freeze's duration is the way to go.
(and I think I already said so).
Some blockers during the freeze have been mentioned on IRC (by Julien, iirc)
that ought to be mentioned here (IMHO) just to keep them in "mind":
1) someone manpower needed to work on release notes
2) not enough contributors fixing RC-bugs
3) people working on upgrade tests and fixing upgrade issues
4) d-i releases are not frequent and take too long, that really slows down
things a bit. It has direct impact on 3).
If we can enhance some of them (hopefully, all of them), we will be able to
reduce freeze's duration, IMHO.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbdbcba.6020...@dogguy.org
