diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-July/017227.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-July/017227.html | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-July/017227.html b/zarb-ml/mageia-dev/2012-July/017227.html new file mode 100644 index 000000000..51cc43598 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-July/017227.html @@ -0,0 +1,140 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%0A%20%3D%3Fiso-8859-1%3Fq%3FSecurity_updates_-_Help_needed_%3D28als%3F%3D%0A%20%3D%3Fiso-8859-1%3Fq%3Fo_forgot%3D09avidemux_and_gstreamer0%3D2E10-ffmpeg%3D29%3F%3D&In-Reply-To=%3C201207081917.21419.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="017224.html"> + <LINK REL="Next" HREF="017181.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%0A%20%3D%3Fiso-8859-1%3Fq%3FSecurity_updates_-_Help_needed_%3D28als%3F%3D%0A%20%3D%3Fiso-8859-1%3Fq%3Fo_forgot%3D09avidemux_and_gstreamer0%3D2E10-ffmpeg%3D29%3F%3D&In-Reply-To=%3C201207081917.21419.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)">stormi at laposte.net + </A><BR> + <I>Sun Jul 8 19:17:21 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="017224.html">[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) +</A></li> + <LI>Next message: <A HREF="017181.html">[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#17227">[ date ]</a> + <a href="thread.html#17227">[ thread ]</a> + <a href="subject.html#17227">[ subject ]</a> + <a href="author.html#17227">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le dimanche 8 juillet 2012 13:49:36, nicolas vigier a écrit : +><i> On Fri, 06 Jul 2012, Claire Robinson wrote: +</I>><i> > This has nothing to do with being rude. +</I>><i> > +</I>><i> > As I said previously, this is being blown wildly out of proportion. In +</I>><i> > reality it centres around one packager and two bugs. In both these bugs +</I>><i> > the packager expected QA to validate updates where one was an xinetd +</I>><i> > service which expressly stated it was disabled by default but in actual +</I>><i> > fact was enabled and in the other a mailing list with a web interface +</I>><i> > which simply couldn't work in it's default configuration. +</I>><i> > +</I>><i> > What it being thrown at us is that we are unreasonably expecting every +</I>><i> > single little bug to be fixed without any common and need to make drastic +</I>><i> > changes to our policies. +</I>><i> > +</I>><i> > We attended the packager meeting on Wednesday to respond to this and +</I>><i> > discuss it. At the meeting it was agreed that we had not changed the way +</I>><i> > we have been doing things since day one and that the right way forward +</I>><i> > was to continue doing what we were doing, with both packagers and QA +</I>><i> > using common sense. +</I>><i> +</I>><i> The argument you keep repeating about your opinion being common sense is +</I>><i> insulting for the people who do not have the same opinion. You could at +</I>><i> least admit that other people may have a different point of view, +</I>><i> without saying they don't have common sense. +</I> +That's not what she said. + +><i> +</I>><i> > The following day the same far fetched accusations are thrown at us +</I>><i> > again, now escalated to the ML, suggesting we caused a months delay and +</I>><i> > suggesting a solution to the accusation being we begin to 'rubber stamp' +</I>><i> > security updates regardless of if they actually work or not or an +</I>><i> > internet facing service which says it's disabled is actually not so. +</I>><i> > +</I>><i> > In both cases there were simple ways to fix them. In one it was just to +</I>><i> > alter the description (2 minutes) so it didn't say it was disabled and in +</I>><i> > the other it was either to add a suggest or alter the default +</I>><i> > configuration so it didn't require the missing suggest (2 minutes). +</I>><i> > +</I>><i> > We have to use common sense in QA and only ask that, to avoid all this +</I>><i> > unpleasantness in the future, common sense is used by the packager also. +</I>><i> > All this is a reaction to 4 minutes of additional work. That is not +</I>><i> > common sense to me. +</I>><i> +</I>><i> Of course if you considere packagers should blindly apply any change +</I>><i> requested without any possible discussion because you decided it's common +</I>><i> sense, it only takes 2 minutes. +</I> +Are you really suggesting that's what Claire thinks or are you just trying to +warm up the atmosphere? + +><i> But conscientious packagers usually try to understand the problem they are +</I>><i> fixing, think about the potential problems introduced by the change, look at +</I>><i> the alternative solutions, etc ... +</I> +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? + +><i> +</I>><i> Also adding new suggests or changing default configuration should be +</I>><i> avoided in updates. The new suggest will be installed even for people +</I>><i> who already have a working setup. And the configuration file will be +</I>><i> updated for the people who did not need to modify it and don't +</I>><i> necessarily expect this kind of change in an update. +</I> +Point noted. + +><i> +</I>><i> > If we're expected to validate updates in the state these two bugs reached +</I>><i> > us then we may as well not be here at all. +</I>><i> +</I>><i> The goal of updates testing is to find regressions, not to do extensive +</I>><i> testing to find new unrelated bugs. This kind of testing can be useful, +</I>><i> but not as part of updates testing, and preferably on Cauldron. +</I> +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 +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="017224.html">[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) +</A></li> + <LI>Next message: <A HREF="017181.html">[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#17227">[ date ]</a> + <a href="thread.html#17227">[ thread ]</a> + <a href="subject.html#17227">[ subject ]</a> + <a href="author.html#17227">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |