Blockers via flags?

Jesse Keating jkeating at redhat.com
Tue May 11 04:40:37 UTC 2010


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.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100510/f5b14186/attachment-0001.bin 


More information about the devel mailing list