On 05/07/12 22:51, nicolas vigier wrote:
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.
The trouble with this is, when the packager finds some free time it then
creates yet another update request for QA to validate and compounds the
problem. We simply have to apply common sense. If something is easily
fixed, fix it. If it isn't then ask for a separate bug report. There is
no black and white policy for this, either extreme is wrong.
I would hope that any packager sending an update for validation would be
willing to follow that up and not just abandon it and move on, becoming
annoyed when problems are found.
You wouldn't expect QA to do that on our bug reports, you would rightly
expect us to follow them up and provide any extra information and
testing as required. Even knowing how busy we are.
I am sure bug reports from our general userbase are not so keenly
monitored or completely reported as the ones we create.
This was all discussed yesterday. There is no real problem to resolve,
other than finding more people to volunteer their time. This hostility
towards QA is rather detrimental to that particular cause though.
The methods we use are tried and tested, and have remained unchanged
since the first updates began to arrive for Mageia 1. There is no reason
to change them now and certainly no reason to begin taking shortcuts.
QA is not there to 'rubber stamp' updates, we are there to perform QA.
To view things from a users perspective and try to find the bugs before
they reach them. We have to apply common sense in our work and only ask
that packagers do the same thing.
None of us want to see buggy updates being released or unnecessary
delays I'm sure.
Claire
