[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)

andre999 andre999mga at laposte.net
Fri Jul 6 02:27:05 CEST 2012


AL13N a écrit :
> Op donderdag 5 juli 2012 21:31:50 schreef Guillaume Rousse:
>    
>> I spent some time today to help the QA team to manage those pending
>> security updates. And for the second time in a week, I've been facing
>> rather unpleasant attitude from someone else from the same team:
>> https://bugs.mageia.org/show_bug.cgi?id=5939
>>
>> I wonder how we're supposed to work together when expressing an opinion
>> about issues prioritization expose you to harsh comment from someone
>> unable to express his disagreement without agressivity. That's not much
>> point ressorting to "we're all in the same boat" kind of metaphor during
>> IRC meeting to thereafter suggest to leave the board to people
>> expressing concerns about the boat heading...
>>
>> So, before any further contribution from my side, I'd like the people in
>> charge of security updates to find some internal agreement about what
>> kind of help they expect from other people exactly. If that's just to
>> push a non-discussable list of changes into spec files, they could as
>> well ask for SVN commit and package submission rights, to do it
>> directly. This would avoid a large amount of anger and frustration for
>> everyone.
>>      
> this is a good point: "BTW, a missing dependency should not be
> considered a blocking issue as it can be easily fixed by the end user.
> Especially for a security update, as he probably already done it."
>    

Although if it can be easily added, why not do it ?  Even if only a 
suggest ?
> also, not sure, but it seems the tester was unawere of perl-CGI-Fast being not
> really required (i think).
>    

According to the comments in the bug, an optional package was required 
by the default config file, even if the package was not installed.  That 
is a real bug.
Adding a suggest is a temporary, and not permanent fix, as suggests 
don't have to be installed.  Although the permanent fix could be done later.

This brings up another improvement that is needed in the install 
routines.  Suggests should be treated as suggests, with confirmation 
from the user on install.  As such, QA could more readily test and find 
such bugs.

> still, IRC meeting yesterday seemed to conclude that security or major bug
> updates cannot be majorly delayed by bugs, it is however ok, to ask packager
> to do a quick fix for something at the same time.
>
> still, for this issue, it seems also that there was a month delay due to not
> setting assigned back. or even setting NEEDINFO.
>
> also, i notice that noone seemed to have pointed out the tester that in fact
> that dependency isn't required.
>
> i also see that some sentences look harsh to one of both sides here. (or at
> least to me).
>
> i think we need to understand that:
>
> A. QA team has responsibility on validation of update
>   - thus they decide validated or not
>   - if they find a non-regression bug, they can ask packagers to fix at the same
> time, but for major and security bugs, this should not be waited for, in such
> a case, a separate bug can be made and this one validated.
>   - however, i can also understand that due to the amount of updates needed
> validation, that such a wait, could be instead of 1 day, easily amount to a
> few weeks, without this being intentional.
>   - so, i would ask that QA, try to get the packager on IRC (or email) and if
> the packager isn't immediately available, to still continue to validate and
> possibly make a new bug report on it. so that "bugs" or "features" can still
> be discussed if need be.
>   -  give that packagers are responsible for their package (and likely know it
> better than QA team), i would state that they are also responsible for
> deciding need or no (immediate) need for extra change before validation.
>
> B. QA team tests and finds bugs, and the reality of their pov is that if they'd
> put bugs they find in a separate BR, it often doesn't get fixed, and thus each
> validation test for all newer security patches, they hit the same bug for
> testing; which causes them frustration.
>
> C. However, some packages need quite some configuration to get it to run to
> test, so packagers are allowed to add a small list of how to reproduce, or
> even configure it to run. as this will likely make for faster testing, and also
> less possibilities of misunderstanding a possible missing requirement.
>
> Personally, I think regarding this quite some things could've been done
> better, but we can't have it all.
>
> i don't think there's a golden rule for this, and given our limited resources,
> i guess we (both teams) will have to bear with this.
>
>
> PS: i'm just putting my nose in matter that don't concern me here, but i'm
> just trying to understand both sides, i'm not trying to offend anyone, or to
> belittle any of the issues involved.
>    
+1

Sometimes when things get frustrating, a few kind words from both sides 
can help a lot.
And maybe step back and smile a little.
But it certainly can be difficult.

-- 
André



More information about the Mageia-dev mailing list