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

Tue Nov 15 12:13:48 CET 2011

Le mardi 15 novembre 2011 07:40:13 Michael Scherer a écrit :
+[...]
+> > 
+> >  - 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.
+Well to be honest i can't be sure that a minor version of KDE is *reallly* bug 
+fixes only, even if it's wrote like this upstream.
+> 
+> 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 ?
+Did we have from the start the minimum of people able to use & came in the 
+situation of trigger them ?
+
+
+> Do we have open bug reports about them, with clear reproducer ?
+The answer here depends of above.
+But the question about having bug reports about them with *clear* reproducer 
+is interresting.
+Let's take an example :
+
+If an end user found a bug/crash in kdeenlive he might be not able to provide 
+a clear way to reproduce it because he's using some specific codecs with 
+specific options and so he might be able to provide only the backtrace.
+Sometimes upstream can directly fix the crash using this backtrace because it's 
+obvious (from a coder point of view of course , not from my point of view :p 
+), so the end user will be happy.
+What should we do in that case ? backport the patch for a crash where we don't 
+have any reproducer to ensure our QA is able to test & report it fixed ? or 
+just ignore it because of our policy ?
+because of course fixing this bug could introduce another one etc etc.
+
+Perhaps some users of kdenlive of mageia noticed some of thoses 
+crash/corruption but did not report them on mageia's bugzilla because 
+- they don't know how to do it or not able to provide a « clear » way to 
+reproduce it
+- they report directly upstream 
+
+Sticking to a have a clear reproducer to get a patch available in our package 
+might reduce the chance of passing the QA :)
+
+
+> And do at least someone plan to use kdenlive enough to say "this fixed
+> the bug I have been seeing before" ?
+I'm not sure we have enough users to ensure that some of them will report the 
+bug on our bugzilla, not to mention the fact that some users still see the 
+bugzilla as a write only media...
+
+
+> Or do we plan to do "it started, so it is good enough, let's ship it" ?
+Here's the packager is supposed to provides a list of things to test & not let 
+QA alone.
+Regarding kdeenlive for example every issue listed on the changelog is linked 
+to their bugzilla so the packager (poor juancho :p ) might be able to provide 
+a list of things to test.
+
+Also we should not forget that our process for backports is the same so QA 
+will need to do the same work (that's also why i personnaly won't backport 
+anything to ease the work for our small QA) so the idea of pushing kdenlive to 
+backports instead of updates does not solve the situation from a QA 
+perspective.
+
+Anyway since it's our policy i'll stick strictly on it now to avoid this kind 
+of situation (& next time i'll try to follow with more attention our work on 
+policy :p). I'll try also to manager sometimes to take part of the QA process 
+to increase the number of people available in this team.
+
+
+Regards,
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+