From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-June/005951.html | 106 +++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005951.html (limited to 'zarb-ml/mageia-dev/2011-June/005951.html') diff --git a/zarb-ml/mageia-dev/2011-June/005951.html b/zarb-ml/mageia-dev/2011-June/005951.html new file mode 100644 index 000000000..7833dba94 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005951.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ andre999 + andr55 at laposte.net +
+ Thu Jun 23 05:10:01 CEST 2011 +

+
+ +
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é
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1