Two suggestions for possible changes in blocker bug procedures: 1. I think more burden should be placed on he who proposes a bug as a blocker. a.) what release criterion applies b.) what workarounds are there c.) what are the contra-arguments to blocking 2. The above information would be useful in scanning blocker bugs, and triaging their review. I'm not clear on the method for ordering the review, but it would probably be helpful getting non-QA participation if say, anaconda bugs were being reviewed all at once and in triaged order. The Wednesday scheduled blocker meeting should not, in my view, be "dicking around" with reviewers trying to infer why a bug was proposed as blocker. I'd relegate such bugs to last call or see those bumped to an unscheduled day. Something like that. Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test