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

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é
+
+