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

[nicolas vigier]

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.