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@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Reply via email to