On Wed, 2012-10-24 at 19:38 -0600, Vincent Danen wrote: > So if you're looking at alpha's as having all criticals fixed, I think > you can say that is quite well understood and I don't think it's a > problem. > > Important-impact issues in beta and release is totally doable. It's the > lower-impact stuff I'd like to see resolved properly. For this thread I want to keep it to what goes in the release criteria, if we can. If we spread the discussion too wide we'll never get done. Note that, if I'm understanding your mail correct, what you call 'persistent flaws' is what I'm referring to when I talk about 'cannot be fully resolved by a package update' - we're talking about stuff in the install process or live boot or first boot, which we can't resolve just by shipping an update. That's why I made that distinction and gave those bugs, in general, more importance. What's your opinion on "moderate bugs that can't be fixed by updates" (i.e. persistent flaws) as a Final blocker? Is that going too far? Note the blocker process is pretty much orthogonal to priority/severity. A blocker issue for Fedora is a blocker. We don't ship the release without fixing it. It's a very simple binary state. It doesn't matter what priority/severity a blocker bug happens to get assigned, it must be fixed for the release to go out. > Our rule for RHEL is no known important+ security flaws. This may lead > to a bunch of 0-day errata to get things squared away at GA (if we find > out about something post-freeze, etc.). This is for "dot" releases, > like 6.2 or 6.3. For a new "dot-0" release the rules are different. > For those releases, we absolutely strive for no known security flaws of > _any_ impact. We don't want to release a product with known security > issues. > > How does that equate to Fedora? I don't know. Do we look at Fedora's > quick release cycle as a series of ".X" releases? Or are they all ".0" > releases? I'd love to see them as ".0" with no known security issues, > but I suspect that won't happen anytime soon. =) Yeah, that would be too ambitious. The other difference in Fedora is we don't consider 0-day updates part of a release. We ship a bunch of 0-days, but they're just not considered in the 'release process', except in very special circumstances. Blocker bugs have to be fixed *in the release package set* (what gets frozen). > To me, no known important+ flaws at a Fedora GA is a doable goal, and > I'm pretty sure that more often than not we achieve that without really > aiming for it. Making this into some sort of policy makes sure it's > followed, but I think the real benefactor to this policy would be > Anaconda. Really it's just about getting things into the policy. 'Achieving the goal without really aiming for it' is fine and all, but it's not bulletproof :) There've been a few cases where we've kinda wanted to take security bugs as blockers but simply haven't had a framework for it. We're very strict on the blocker process these days: we don't just throw the 'blocker' status around arbitrarily. There _has_ to be a justification for it in the criteria. > I'd like to see some kind of improved policy for dealing with security > bugs in Fedora in general, but I think that is a resource problem and > the fact that the Fedora Security Response Team really doesn't do > anything. Most of the duties that it would have, Red Hat Security > Response handles. The real "hole" in our process is we don't > followup/badger/whatever once these tracking bugs are filed. We tend to > fire and forget, which may be the wrong approach, but is really the only > one that works for us due to time/resource constraints. > > Perhaps the Fedora Security Response Team could be more formalized and > chase those things? Maybe that's a good first step to aim for? > > That might be outside the scope of what you're bringing up here, Adam. > Sorry if you feel like maybe you opened a can of worms. You just gave > me a soap-box I've been eyeing for a few years. =) Yes, I think we're somewhat out of scope here. If you want to start up that discussion then go for it, but I'd _really_ like to keep criterion proposal threads on track, because they're not talking shops. Criteria revisions are important actions in QA, this isn't just a trial balloon, the intent is to put something in place in a fairly short term here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
