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

Sun Jul 8 19:17:21 CEST 2012

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
+