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 --- .../attachments/20120713/c9b894d2/attachment.html | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 zarb-ml/mageia-dev/attachments/20120713/c9b894d2/attachment.html (limited to 'zarb-ml/mageia-dev/attachments/20120713/c9b894d2/attachment.html') diff --git a/zarb-ml/mageia-dev/attachments/20120713/c9b894d2/attachment.html b/zarb-ml/mageia-dev/attachments/20120713/c9b894d2/attachment.html new file mode 100644 index 000000000..9adb3b6e4 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20120713/c9b894d2/attachment.html @@ -0,0 +1,50 @@ + + +

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

\ No newline at end of file -- cgit v1.2.1