On Tue, 24 May 2011, Michael Scherer wrote:
Le mardi 24 mai 2011 à 12:45 +0200, nicolas vigier a écrit :
On Tue, 24 May 2011, Christiaan Welvaart wrote:
On Tue, 24 May 2011, Michael Scherer wrote:
There is 2 proposal :
- filling them on security, and have a saved search
- creating a tracker bug
I would be in favor of the tracker bug :
- you can subscribe to it
- it will be clearer ( as bugfixes are not security so we may miss some
update to do )
- it doesn't pollute the list of saved search
But as pascal said, a tracker bug requires that each bug to be linked to
it, which is manual and error prone.
I don't know much about bugzilla, but:
- Add a keyword 'security' to all security bugs.
(also manual and error prone?)
We already have a security component. Would a keyword instead of a
component be better for this ?
What when we have more than 1 release ?
I really think the security component is wrongly named. The bug is
against a rpm package, be it a security or non security fix, and
treating security fix differently than non security fixes add IMHO
unneeded complexity to the process.
I agree with Michael: security is not a component: a security issue in a
package is still a bug in that package. (And I still consider each source
rpm a component like originally configured in the mandrake bugzilla).
It is also manual, but a keywork is easier to remember than a tracker
bug number.
That's a good point, I guess we can either place the link on bugzilla
main page, or use named bugs, or something like that ?
There is a 'version' in bugzilla, with only 'Cauldron' in it currently,
maybe that should be used. Setting this (or a target milestone) for a bug
is easy, just choose 'Mageia 1' from the list. So if you want to see all
updates in the list, make a search for bugs with version (or target
milestone) Mageia 1. A link on the main page would be fine with me. It's a
trivial search, however (:
Maybe we can also think about a mailing list to receive all security
bugs.
It doesn't take non security related fix in account.
Given the fact that there is no difference between the way we treat them
( ie, it is updates ), and given the fact than even later the difference
will be between embargoed updates and the rest, I guess that a generic
list for issue affecting a stable release would be better suited.
But I am not sure it will help much, we need to think to the problem we
try to solve, and the way I see it, it is twofold :
- we need to have a list of thing to update ( security or not, doesn't
matter now )
- we need a way to be aware of changes to the aformentioned list
Maybe there can be a trigger in bugzilla on all bugs that are newly
targeted or retargeted at a stable release?
The solutions must :
- be extensible with possibility of having a embargo in the future
AFAIK bugzilla supports access restrictions on individual bugs.
- be as automated as possible
- be open to people that want to help
- take in account that we will have more than 1 release, maybe more than
1 project
Products and releases are already supported in the current bugzilla
configuration.
Christiaan
