sorry, I forgot to strip off everything at the beginning ... so if you could ignore the previous email
andre999 a écrit :
I'd like to consolidate and clarify my ideas regarding an amended freeze process, taking into account the critiques. That is, that for the freeze which leads to the release, that we 1) freeze cauldron 2) copy caudron to a pre-release branch, which remains frozen, and will become the release 3) then unfreeze cauldron. - this would be the first freeze, when the big focus starts on bug fixes. The sequence of freeze types would not (necessarily) change. - although cauldron would be unfrozen, the idea is to allow small contributions, such as new packages, new versions not accepted into pre-release, etc. But not to have major changes which could break cauldron, as the main contributors will be focused, as now, on pre-release, and major breaks in cauldron should be quickly fixed. So that cauldron would not be not totally blocked to all non-release contributions during the freeze period (which was about 6 weeks for mga1). - It would probably be very useful to have an explicit policy limiting the nature of contributions to cauldron during the pre-release period. We could even encourage the importing of new packages during this period. - Caudron unfrozen would also allow less experienced packagers to contribute to cauldron at times when they are unable to usefully contribute to pre-release. For instance, such packagers could depend heavily on the advice of others for bug fixes, but could be advanced enough to import new packages or new versions to cauldron on their own. (idea from comment on mageia1_postmortum wiki page.) - This process assumes that the freeze period would be extended (by maybe 2 weeks) to give more time to fix bugs, relieving some of the pressure. Those less able to efficiently contribute to pre-release could contribute to cauldron, so the extra time would be needed. - If this amended process allows us to more easily make the release, and thus keep the release cycle of 6 months, we would have the advantage of keeping in sync with upstream for major projects such as kde and gnome. But if not enough for keeping the 6-month release cycle, if it helps, let's use it if we go with a longer cycle. - In no way is the idea to produce parallel development streams as is now done by mozilla for firefox. Hopefully this summary helps. (BTW, it is still Wednesday in my time zone.) On the road to mga2 ... :)
-- André
