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/005568.html | 188 +++++++++++++++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005568.html (limited to 'zarb-ml/mageia-dev/2011-June/005568.html') diff --git a/zarb-ml/mageia-dev/2011-June/005568.html b/zarb-ml/mageia-dev/2011-June/005568.html new file mode 100644 index 000000000..9d2faf178 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005568.html @@ -0,0 +1,188 @@ + + + + [Mageia-dev] Release cycles proposals, and discussion + + + + + + + + + +

[Mageia-dev] Release cycles proposals, and discussion

+ Michael Scherer + misc at zarb.org +
+ Tue Jun 14 01:31:46 CEST 2011 +

+
+ +
Le lundi 13 juin 2011 à 14:20 +0200, Wolfgang Bornath a écrit :
+
+> The 9-months seem to be a compromise - but I start to ask why we need
+> such a fixed statement (which it would be, once published). We need a
+> schedule for each cycle, that's true. Without a schedule we would
+> never finish anything. But how about taking 9 months only as a "nice
+> to meet" target, leaving us the option to set a roadmap after setting
+> the specs of the next release - we could then go for a 8 or 10 months
+> roadmap, depending on the specs.
+
+As I said to Thomas, we will never use the 8 months option. If we say
+"we have selected less features to finish sooner", people will just ask
+for more features, and will say "why do you want to finish sooner, I
+prefer to have feature and wait 1 month more". 
+
+In fact, the same would go for 9 to 10 if we start to propose the
+possibility. 
+
+And deciding that we will decide later is not really deciding. We should
+select features based on time needed to implement them and how much time
+we can devote, not the contrary especially since no one will ever be
+able to give precise timing for anything, so one month of difference
+would be difficult to justify.  
+
+And I think we can already decide to release 1 week later if a
+release_critical bug appears. Fedora 15 for example was 2 weeks late,
+because they changed the release date twice after having seen some
+problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).
+
+And we did it more than once at Mandriva.
+
+> This being said, I am a friend of a rolling release like ArchLinux,
+> but I fear that our main target group is not up to this. Despite of
+> having to "burn yet another DVD" as somebody pointed out, the majority
+> seems to see this as normal and a good way. Of course I may be totally
+> wrong with this assessment!
+
+Maybe people should maybe start to trust more mgaonline to do upgrade,
+there is nothing that pacman does that urpmi don't regarding upgrade,
+there is no magic involved : 
+- people should test before the release and fill bug reports.
+
+That's the secret behind debian upgrade, people just do lots of tests
+for that either automated ( using something like piupart
+( http://wiki.debian.org/piuparts ) ), or manual and lots of people do
+full system upgrade long before the release ( and not only after ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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