Review of Fedora 18 Release Criteria

Tim Flink tflink at redhat.com
Wed Oct 10 22:33:15 UTC 2012


On Wed, 10 Oct 2012 15:35:11 -0600
Chris Murphy <lists at colorremedies.com> wrote:

> 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

Honestly, I'd like to change the way that most people propose
blocker/nth bugs.

What I'd like to do is extend the tracking app to have a 'propose a
blocker' link. That link would lead to a form to fill out, including
the criterion that's being violated and a justification.

My feeling is that our current process is a little obtuse for those
who aren't familiar with it - by making the easy path for proposing
blocker/nth bugs include criteria, I suspect that we wouldn't see so
many proposed blockers with no justification or explanation.

> 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.

Yeah, that's my fault. I keep forgetting to implement sorting in the
code I use to generate  the list of bugs to review. As I mentioned
before, I'm going to fix that for the meeting continuation tomorrow and
do that going forward.

What do you mean by 'triaged order'? I can think of a couple ways that
could be read but I'm not sure which one you were thinking of.

> 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.

Unfortunately, with our current process and tools, that would require a
person/people to go through all of the proposed blockers before the
meeting and mark the bugs that aren't ready for review.

If we can find someone to go through all the bugs and pester people
about "why is this a blocker?" and "are there workarounds?", that would
be great but I suspect that finding someone to do the work would almost
be more of a challenge than writing a tool to help (and that would take
time).

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20121010/023f46e6/attachment.sig>


More information about the test mailing list