From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-July/017224.html | 121 +++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-July/017224.html (limited to 'zarb-ml/mageia-dev/2012-July/017224.html') diff --git a/zarb-ml/mageia-dev/2012-July/017224.html b/zarb-ml/mageia-dev/2012-July/017224.html new file mode 100644 index 000000000..ec5734afc --- /dev/null +++ b/zarb-ml/mageia-dev/2012-July/017224.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg) + + + + + + + + + +

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

+ nicolas vigier + boklm at mars-attacks.org +
+ Sun Jul 8 13:49:36 CEST 2012 +

+
+ +
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.
+
+> 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. 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 ...
+
+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.
+
+> 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.
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1