[Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
mikala at mageia.org
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
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
- 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
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
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.
Jabber-id: mikala at jabber.littleboboy.net
More information about the Mageia-dev