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-November/009553.html | 109 +++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-November/009553.html (limited to 'zarb-ml/mageia-dev/2011-November/009553.html') diff --git a/zarb-ml/mageia-dev/2011-November/009553.html b/zarb-ml/mageia-dev/2011-November/009553.html new file mode 100644 index 000000000..c5e99901d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-November/009553.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2 + + + + + + + + + +

[Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Nov 15 11:59:26 CET 2011 +

+
+ +
Am 15.11.2011 07:40, schrieb Michael Scherer:
+> Le lundi 14 novembre 2011 à 19:29 -0300, Balcaen John a écrit :
+>> Le lundi 14 novembre 2011 23:17:32 zezinho a écrit :
+>>> Le lundi 14 novembre 2011 20:23:40, Juan Luis Baptiste a écrit :
+>>>> So what is the final decision about this ? is there going to be an
+>>>> update or not ?
+>>> I vote no, let's wait for backports, like all other new versions.
+>> i not agree at all because 
+>>  - we did it for KDE SC 4.6 (upgrading from 4.6.3 to 4.6.5).
+>>  - the list of bug fixes  (especially the number of crash & corruption fix)
+>>  - it's a *minor* version not a major one
+> The policy is not about minor version, it is bugfixes only. Not
+> everybody make the distinction between minor and major, especially for
+> software developpers.
+>
+> And again, the question of QA is here. Since we didn't detect the
+> regression ( and since there is so much crashes to fix, and sine
+> everybody think that's important enough to bypass our policy, according
+> to people in the thread ), how do people plan to make sure the most
+> obvious one are corrected ? 
+>
+> Do we have open bug reports about them, with clear reproducer ?
+>
+> And do at least someone plan to use kdenlive enough to say "this fixed
+> the bug I have been seeing before" ? 
+>
+> Or do we plan to do "it started, so it is good enough, let's ship it" ? 
+So your proposal is to basically redo the whole upstream work and separating
+the bugfixes from the new features? If this isn't done by an experienced developer,
+i think the chances of adding regressions in doing this for the 140 bugfixes
+or whatever is higher than directly using upstream release.
+
+Also i think this, measuring with two scales, and maybe over-simplifying it is
+a bit unfair, we had KDE bugfix/feature updates, and now we say:
+No, we can't do this? Either only bugfix through patches or no update at all?
+
+
+An example: For ffmpeg, to fix the reported multiple security issues,
+as 0.6 branch is not supported upstream anymore, basically we'd need
+to go over through 7500 commits, check if they are bugfix or security-
+related, and cherrypick the relevant ones. I don't have enough C/git
+knowledge to do this, and Anssi is quite short on spare time, so it may
+take a while to get this done. In some rare cases it is either really really
+difficult or not doable due to manpower constraints.
+
+
+Also i'd like to notice that we don't do automated regression testing or
+unit tests, and we were at the process of bootstrapping mageia where
+the tests should have gotten this. IMHO you can't possibly expect that,
+there were simply not enough endusers to catch such bugs/regressions.
+
+In a perfect world, yes, sure, but remember we're not in an ideal, perfect world.
+
+ + + + +
+

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