Blockers via flags?

[Thomas Janssen]

On Tue, May 11, 2010 at 6:40 AM, Jesse Keating <jkeating at redhat.com> wrote:
> On Mon, 2010-05-10 at 22:47 -0500, Garrett Holmstrom wrote:
>> Fedora only has one branched, yet unreleased release at a time.  Can we
>> recycle the same tag(s) for every release instead of creating new ones
>> every time?
>
> We could probably name them such, just {alpha,beta,final}_blocker, and
> only make them available to the release that is in "branched" mode.  I
> say probably, as I've done 0 research on the subject.
>
>>
>> > How does it solve the problem(s)?  We can query against flags and find
>> > the bugs that have been accepted as blockers, which will help developers
>> > find issues which are critical to be worked on.  It'll help our testers
>> > find issues which are determined to be blockers and have a fix that
>> > needs to be verified.  It'll help our qa/releng folks focus on issues
>> > that are proposed but not yet accepted as blockers.  It will also allow
>> > us to process potential blockers as they come up asynchronously as
>> > opposed to waiting for the next Friday grind and spend hours working
>> > through the list synchronously.  Ideally that will allow us to reach a
>> > conclusion about a proposed blocker faster and with less overhead, so
>> > that we can spend the meeting time discussing the truly interesting and
>> > difficult issues that require discussion.
>>
>> I don't understand how using a flag instead of a tracking bug makes this
>> less work.  Under the current system proposed blockers show up, get
>> discussed, then possibly shot down.  Under your proposed system proposed
>> blockers will show up, get discussed, then possibly acknowledged as
>> such.  Where is the time savings?
>
> Under the current system, the acceptance or removal of a blocker
> generally only happens during the Friday meetings.  Under the new
> system, releng can at their convenience run through the proposed list
> and cast their vote.  QA can do the same, as can developers.  This can
> all happen in async and more frequently than the waiting for the next
> Friday meeting.

Very good idea. +1

-- 
LG Thomas

Dubium sapientiae initium