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

[Balcaen John]

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