User:Jlaska/Draft

This page attempts to capture all concerns around the Fedora 12 schedule and outline recommendations for each concern.

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

1. I think we should be doing the first blocker review day a week earlier
2. I think that blocker review for a given snapshot (alpha, beta) should happen at least 7 days before the freeze for said snapshot
3. 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 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

1. 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
2. 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.
3. 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