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

[Samuel Verschelde]

Le dimanche 8 juillet 2012 13:49:36, nicolas vigier a écrit :
> On Fri, 06 Jul 2012, Claire Robinson wrote:
> > This has nothing to do with being rude.
> > 
> > As I said previously, this is being blown wildly out of proportion. In
> > reality it centres around one packager and two bugs. In both these bugs
> > the packager expected QA to validate updates where one was an xinetd
> > service which expressly stated it was disabled by default but in actual
> > fact was enabled and in the other a mailing list with a web interface
> > which simply couldn't work in it's default configuration.
> > 
> > What it being thrown at us is that we are unreasonably expecting every
> > single little bug to be fixed without any common and need to make drastic
> > changes to our policies.
> > 
> > We attended the packager meeting on Wednesday to respond to this and
> > discuss it. At the meeting it was agreed that we had not changed the way
> > we have been doing things since day one and that the right way forward
> > was to continue doing what we were doing, with both packagers and QA
> > using common sense.
> 
> The argument you keep repeating about your opinion being common sense is
> insulting for the people who do not have the same opinion. You could at
> least admit that other people may have a different point of view,
> without saying they don't have common sense.

That's not what she said.

> 
> > The following day the same far fetched accusations are thrown at us
> > again, now escalated to the ML, suggesting we caused a months delay and
> > suggesting a solution to the accusation being we begin to 'rubber stamp'
> > security updates regardless of if they actually work or not or an
> > internet facing service which says it's disabled is actually not so.
> > 
> > In both cases there were simple ways to fix them. In one it was just to
> > alter the description (2 minutes) so it didn't say it was disabled and in
> > the other it was either to add a suggest or alter the default
> > configuration so it didn't require the missing suggest (2 minutes).
> > 
> > We have to use common sense in QA and only ask that, to avoid all this
> > unpleasantness in the future, common sense is used by the packager also.
> > All this is a reaction to 4 minutes of additional work. That is not
> > common sense to me.
> 
> Of course if you considere packagers should blindly apply any change
> requested without any possible discussion because you decided it's common
> sense, it only takes 2 minutes. 

Are you really suggesting that's what Claire thinks or are you just trying to 
warm up the atmosphere?

> But conscientious packagers usually try to understand the problem they are
> fixing, think about the potential  problems introduced by the change, look at
> the alternative solutions, etc ...

Of course. Why do you seem to think that when a QA member raises a point 
he/she considers it's an order rather than a bug report?

> 
> Also adding new suggests or changing default configuration should be
> avoided in updates. The new suggest will be installed even for people
> who already have a working setup. And the configuration file will be
> updated for the people who did not need to modify it and don't
> necessarily expect this kind of change in an update.

Point noted.

> 
> > If we're expected to validate updates in the state these two bugs reached
> > us then we may as well not be here at all.
> 
> The goal of updates testing is to find regressions, not to do extensive
> testing to find new unrelated bugs. This kind of testing can be useful,
> but not as part of updates testing, and preferably on Cauldron.

This is the same kind of testing, we look for bugs then we can see if they are 
regressions or not. They don't have "hey I'm a regression flag, test here!" 
flags :)
But I agree with the fact that only regressions can block an update, the other 
bugs being left to the packager's appreciation.

Samuel