diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-July/017198.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-July/017198.html | 157 |
1 files changed, 157 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-July/017198.html b/zarb-ml/mageia-dev/2012-July/017198.html new file mode 100644 index 000000000..d1591ee86 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-July/017198.html @@ -0,0 +1,157 @@ +<!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%20Security%20updates%20-%20Help%20needed%20%28also%0A%20forgot%09avidemux%20and%20gstreamer0.10-ffmpeg%29&In-Reply-To=%3C5fda6a6bf85d4c7dd6d7dbdff13f2faf.squirrel%40mail.rmail.be%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="017194.html"> + <LINK REL="Next" HREF="017200.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)</H1> + <B>AL13N</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Security%20updates%20-%20Help%20needed%20%28also%0A%20forgot%09avidemux%20and%20gstreamer0.10-ffmpeg%29&In-Reply-To=%3C5fda6a6bf85d4c7dd6d7dbdff13f2faf.squirrel%40mail.rmail.be%3E" + TITLE="[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)">alien at rmail.be + </A><BR> + <I>Fri Jul 6 13:19:41 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="017194.html">[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) +</A></li> + <LI>Next message: <A HREF="017200.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#17198">[ date ]</a> + <a href="thread.html#17198">[ thread ]</a> + <a href="subject.html#17198">[ subject ]</a> + <a href="author.html#17198">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>><i> On 06/07/12 07:56, Oliver Burger wrote: +</I>[...] +><i> This has nothing to do with being rude. +</I> +IIUC, a small bit of it is related in 2 instances (from my pov): + - QA team being ignored in their question + - packager being doubted by QA team + +(in some or other forms, both of these can be seen as rude) + +for one more perceived rudeness, look below. + +><i> As I said previously, this is being blown wildly out of proportion. +</I> +very true + +><i> 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 +</I>><i> drastic changes to our policies. +</I> +i did mention it would best for packagers (and i think it's in policy) +that they would give reproducer tests for validation (perhaps it should be +extended to getting the package working as well) + +><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> +IIUC, not 100% the same, security updates should get pushed without delay +even if there's an additional problem (unless regressions). The idea +behind this, is that security updates are important for people who are +already running it. and since they are running it, they aren't likely to +have the problems that QA had. + +I have no trouble having contacting packager and ask for fix, but +ultimately, for if for whatever reason the packager isn't there, i still +think it should be pushed. + +><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> +This is also perceived rudeness: +- The packager's pov is that QA should have pushed it anyway. +- personally, i'm not certain that this is the intention of the person who +wrote it. + +The problem in this exact case, is that in fact, IMHO, the suggested +modification, wasn't needed; allthough it might be better, it's ultimately +not needed, because having a mailinglist, you need to configure alot of +things anyway. and perhaps it's not even required to use CGI::Fast +(depending on configuration). arguably it's perhaps better to have this as +suggest. + +The packager's pov is that QA team was stating a undiscussable MUST that +this dependency should be required (not suggested; which is better), while +in effect, afterwards, it appears that this dependency is a separate and +not even a major bug (easy workaround). + +But, QA team doesn't know alot about this. so i'm not speaking about +faults here. +Also packaging team must realize that QA team doesn't know alot about +this. They are just doing what they think is right. + +but if packaging team says that this isn't really a major requirement for +this security bug, then again, QA team should understand this too. + + +><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 +</I>><i> in 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> +That is also true. + +><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> If we're expected to validate updates in the state these two bugs +</I>><i> reached us then we may as well not be here at all. +</I> +no offense meant, but in retrospect, it appears those new bugs in those 2 +bug reports (to me) aren't that major at all. + +but I agree that it isn't easy to test, and thus packager should be +accomodating that. +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="017194.html">[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) +</A></li> + <LI>Next message: <A HREF="017200.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#17198">[ date ]</a> + <a href="thread.html#17198">[ thread ]</a> + <a href="subject.html#17198">[ subject ]</a> + <a href="author.html#17198">[ 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> |