From Fedora Project Wiki
m (Updated content)
m (Minor changes)
Line 1: Line 1:
This page attempts to capture all concerns around the Fedora 12 schedule and outline recommendations for each concern.
Nothing yet
 
= Blocker bug review timing =
 
== Problem ==
 
As scheduled, blocker bug reviews do not provide enough time to process the review feedback and get fixes in.
 
== Proposals ==
 
# I think we should be doing the first blocker review day a week earlier
# I think that blocker review for a given snapshot (alpha, beta) should happen at least 7 days before the freeze for said snapshot
# There should be a blocker review the day of or day before the scheduled RC compose
 
= The term ''RC'' is a lie =
 
As defined in [http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate wikipedia] ...
 
The term release candidate (RC) refers to a version with potential to be a final product, ready to
release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all
product features have been designed, coded and tested through one or more Beta cycles with no
known showstopper-class bug.
 
== Problem ==
 
By scheduling multiple composes of an RC, are we supporting the perception that a Fedora Release Candidate is a '''lie'''?
 
== Proposals ==
 
# We should have a Test Compose a week prior to the freeze.  This gives QA and whomever a chance to put the compose though our test matrix and find the problems before we freeze then once we clear blocker list we can compose a release candidate if it passes the matrix, it goes out
# Once we get RC stage, we make an RC and every single day is a blocker bug review day. Either there are new blockers found and we have to respin, or there aren't and we move on.
# There should be only one scheduled RC compose, and an understanding that it's a day to day thing we make an RC, re-review blocker status until there is a new blocker, make another RC

Revision as of 15:27, 15 July 2009

Nothing yet