[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Which unresolved bugs block a release?



On Wed, 2007-03-21 at 23:04 -0400, Jesse Keating wrote:
> On Wednesday 21 March 2007 22:51:39 John Poelstra wrote:
> > This raised a few questions for me:
> > 1) Is there a mechanism to know which of the bugs above must be fixed or
> > FC7 to GA? 
> 
> Nothing formal.  As we start looking that way a few people generally shuffle 
> through the "Blocker" list to look for actual blockers and get rid of the 
> noise.  Since there is no committee that decides what is or isn't a blocker 
> we can't just take every bug as an actual blocker.

We do actually have some guidelines for this:

http://fedoraproject.org/wiki/QA/ReleaseCriteria

Comments and suggestions gratefully accepted.

> > 2) What process do we go through to close these bugs? 
> 
> Really, that depends on the bug.  Generally we fix it, or find a suitable work 
> around.
> 
> > 3) How does Fedora decide a release is ready to GA?
> 
> Release Engineering in conjunction with QA typically come to an agreement that 
> the tree is "good enough".  Sometimes we have to kick decisions up to the 
> board on what to do about remaining issues.

Again, see the Release Criteria, and also the Tree Testing matrix:
http://fedoraproject.org/wiki/QA/TreeTestingTemplate

> > 4) How are bugs from previous releases considered in the planning process?
> 
> They aren't really, officially.  We try to fix the big glaring ones 
> immediately after the release to prevent them from happening again the next 
> time.  Some previous "blockers" are moved to the next blocker set to be 
> reviewed later.
> 
> Unlike with RHEL, there is no real good management of the blocker/target bugs 
> for Fedora.

The Release Criteria should help with this, but it would be good to have
slightly more work done on tracking bugs so we can do metrics and figure
out some guesses on how much we can actually handle in a given release. 

I say "slightly more work" but there's actually a whole load of stuff
that would be required there: triaging, mass-moving bugs at release
time, gathering bug stats, helping enforce proper bug state changes,
etc.

If someone wants to be the official BugzillaKeeper, I'm sure we've all
got ideas on where that person could start.

-w

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]