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

Thu Jul 5 22:24:23 CEST 2012

Op donderdag 5 juli 2012 21:31:50 schreef Guillaume Rousse:
+> Le 04/07/2012 01:21, David Walser a écrit :
+> > Sorry, think I've got them all now.
+> > 
+> > For avidemux and gstreamer0.10-ffmpeg in Mageia 1, it may be sufficient to
+> > borrow the patches from the mplayer update.
+> > 
+> > For avidemux in Mageia 2, patches will need to be pulled from ffmpeg GIT.
+> > 
+> > https://bugs.mageia.org/show_bug.cgi?id=6427
+> 
+> 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."
+
+also, not sure, but it seems the tester was unawere of perl-CGI-Fast being not 
+really required (i think).
+
+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.
+