Re: time based freezes
On Sun, 2011-04-24 at 20:00 +0000, Sune Vuorela wrote:
On 2011-04-24, Stefano Zacchiroli <firstname.lastname@example.org> wrote:
> Dear Release Team ... good luck in proposing a freeze month now :-)
I would propose mid september or mid-march. That's just after 2nd patch
release of new set of releases by KDE.
And why not new gnome release, or maybe new kernel version or even any other program packaged....
I think that, the best choice is to follow a time based release content definition which may be described by the following procedure.
1) Release team calls for a release content with a target date +/- 3 month.
2) DD answer each with his road map (bugs, new upstream releases, ...) which should fit in for the date, within a month from the call date.
3) Release team, compiling the information, fills bugs for new feature and tag bugs for the next release.
4) DD confirm/infirm the tags within 1 month
5) Release team fixes the freeze date
BTW, if the freeze happens on a separate copy of testing (let's say frozen), it will be great. Uploads should target frozen, be built into it (not into unstable). Only bug fixes are allowed on it.
Description: This is a digitally signed message part