On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote: > If you take into account that the proposal concerns security fixes only, > then every update has to be labeled a security update (and preferably > have some kind of CVE/bug# attached??). We would need to think about a > policy for that, agreed. Yeah, if you pick the line at say "critical" then every update would have a CVE, or would be bundled in bodhi with the package that had the CVE. So say webkit needs updating due to a CVE, you would bundle all the dependent packages in the same update, and the whole update itself would have the CVE listing, and would have just once announcement. > > Without a guarantee for stable ABI/API or stable major/minor version > numbers though some updates may have to be pushed as part of the > dependency stack for a given security bug fix -or not. I guess we'll > need to describe how this should be tackled exactly. See above, should be how we do things now, group related updates into a single bodhi submission, and attach the bugs/CVEs to that single submission. > > > * A measure of success. Some way that you can decide whether or not the > > "Feature" has been a success and should be continued, or whether it is a > > failure and shot not be continued, or should be attempted in some other > > way > > > > The measure of success is particularly hard to state in figures. Just > thinking about some measures of success though, it would include; > > - increased participation from the Fedora side of things > - continuous flow of security updates (and bugs against EOS releases solved) > - increased consumption > > and maybe there's more. Number of subscriptions to an announcement / > errata type of mailing list maybe? Number of subscriptions to a ELC SIG > mailing list? Could go by time it takes to get a CVE discovered/fixed, how many are slipping through, karma on the updates, or just mirrormanager hits on the repos. > > > * A timeline to go with the above to review for success/failure > > > > Here's where the initial proposed extension of 6 months kicks in. I > would say our first review is what is now called "Alpha freeze" -the > milestone where Features are checked for their readiness -whether this > proposal ends up being an actual feature or not. I would think 6 months might be a little too short. Why not give it a year? > > > * A responsible body behind the effort to make regular reports to > > FESCo/Board > > > > This is not up to me ;-) I guess we'll hear from FESCo, on whether they > think this is a feature, on whether they think this is in their mandate, > on whether they think this has to go to the Board. You're driving the feature, but don't want to be responsible for the feature? odd? > > > Who is going to track and discover the security issues? > > > > To be determined. Could be delegated to a (dedicated?) small(er) group > of people within the SIG (to be set up) -maybe the not-so-technical??, > or could be a responsible of each individual participating. Ok, so long as your aware that somebody or somebodies will need to monitor the entire package set for CVEs (something we're probably missing to some extent already). -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
