James Laska said the following on 07/07/2010 05:43 AM Pacific Time: > On Tue, 2010-07-06 at 17:22 -0700, Adam Williamson wrote: >> On Tue, 2010-07-06 at 17:10 -0700, John Poelstra wrote: >>> Hard to believe, but Fedora QA starts its "Pre-Alpha Rawhide Acceptance >>> Test Plan" testing this Thursday (2010-07-08). >>> >>> We've run out of time and run way to implement a new means of tracking >>> blocker bugs for Fedora--previously discussed in the context of using >>> flags in Bugzilla. We'll continue to use the same process we've used >>> for past releases. >> >> Erm, really? We could throw the existing proposal in in an afternoon if >> we wanted to. I was fine with it. Jesse, what was your plan here? > > If there is a solution that addresses the problems identified during > F-13, and it can be implemented in *short* time. It would be > compelling. I'm a fan of solving problems with tooling, but I'm not > convinced that is where our big investment should be for the upcoming > release, or that it fully addresses the problems encountered during > F-13. > > I outlined 3 basic blocker bug process recommendations that are > attainable+sustainable and address the problems we had during F-13 [1]. > If someone feels flags are the better solution, and can develop a > proposal for creating bugzilla flags, the policy for managing them, and > bot automation to enforce them, I'm sure we'd all be happy to provide > feedback. > Long term I think flags will help streamline our process. With the first Alpha blocker bug meetings starting next Friday it doesn't make sense for Fedora 14. I agree there is probably enough time to write a proposal for how it could all work, but not enough time to get feedback on the proposal and definitely not enough time to implement and test everything before using it. We can get better near term impact by addressing the recommendations from the QA retrospective around bugzilla. I'm working on two of the tickets. John -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
