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

Thu Jul 5 23:51:00 CEST 2012

On Thu, 05 Jul 2012, Guillaume Rousse wrote:
+
+> 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.
+
+About prioritization, I think we should remember that :
+- we want security updates quickly, to reduce the time users will have
+  vulnerable systems
+- we don't want regressions in updates, that's why we need QA team to test
+  the updates, and why we avoid major changes in updates
+- all people working on Mageia are volunteers, have limited time and
+  probably other external constraints. We can ask them to make an effort
+  when there is an urgency, but this should not be abused.
+
+So I think it would make sense to have a policy that say that when a
+bug that is not a regression is found while testing an update, it can
+be mentioned for information, but it should not block the validation of
+the update. Packager can fix it while fixing the other issue, if he has
+time, but he doesn't fix it if he is too busy or think it introduce too
+much changes for an update. In that case the issue can be fixed later
+when the packager has some free time, with no hurry.
+
+