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/017319.html | 118 +++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-July/017319.html (limited to 'zarb-ml/mageia-dev/2012-July/017319.html') diff --git a/zarb-ml/mageia-dev/2012-July/017319.html b/zarb-ml/mageia-dev/2012-July/017319.html new file mode 100644 index 000000000..d184648aa --- /dev/null +++ b/zarb-ml/mageia-dev/2012-July/017319.html @@ -0,0 +1,118 @@ + + + + [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)

+ Buchan Milne + bgmilne at zarb.org +
+ Fri Jul 13 16:27:02 CEST 2012 +

+
+ +
On Thursday, 5 July 2012 20:34:02 David Walser wrote:
+> Guillaume Rousse wrote:
+> > So, before any further contribution from my side, I'd like the people in
+> > charge of security updates to find some internal agreement about what
+> > kind of help they expect from other people exactly. If that's just to
+> > push a non-discussable list of changes into spec files, they could as
+> > well ask for SVN commit and package submission rights, to do it
+> > directly. This would avoid a large amount of anger and frustration for
+> > everyone.
+> 
+> Nobody is in charge, which is part of the problem.  I think a lot of us
+> packagers come from Mandriva where we were used to Oden being in charge of
+> updates for stable distros, and therefore not having to worry about it.
+
+While Mandriva had a security team (before Oden, Stew, and before that Stew 
+and Vince). However, that doesn't mean you never had to worry about anything.
+
+> We
+> are a community distro, we have no paid security manager.  It is all of our
+> responsibility to do security updates for stable distros.
+> 
+> As far as what kind of help is expected, it varies per bug really.  Some of
+> them have maintainers that might want to give input.  Some I would like to
+> know from someone else more experienced or who has more at stake in a
+> package how to handle an update when there are choices.  Sometimes other
+> distros have pushed an updated (bugfix-only) version, or patched other bugs
+> as well, rather than just patched the security bug.
+
+IMHO, for a security, the priority is to get the patched binaries out to 
+vulnerable users as soon as possible.
+
+If there is a pre-existing minor issue with the originally released package 
+which an experienced user of the software in question can get around without 
+any problems, a separate bug should be filed, but the minor issue should 
+*NEVER* delay the update.
+
+If the software doesn't start with the default config, the user isn't 
+vulnerable, and we can take more time to fix their problem.
+
+If the admin has fixed the default config issue, then THEY ARE VULNERABLE. For 
+*SECURITY* bugs, addressing their vulnerability is the priority.
+
+Otherwise, we may as well not distinguish between bugfix and security updates.
+
+My expectation is that:
+1)Old security fixes should have the highest priority
+2)Any new security fix should have higher priority than any bugfix
+3)Security updates should be provided within 1 week max
+
+Yes, QA team doesn't have enough resources. Guess what, neither do other 
+teams. But, for me, it was frustrating to dedicate time (when I really didn't 
+have it) to provide packages within 48 hours (24 for Mageia 2), and then have 
+a 3-4 week delay in validation, mainly because of some minor pre-existing 
+issues with the Mageia 1 package (which had been solved in the Mageia 2 relase 
+package).
+
+Regards,
+Buchan
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20120713/c9b894d2/attachment-0001.html>
+
+ + + + +
+

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