As the Fedora Board and larger community has discussed what we want our releases to be and who they are for–Target Audience–I’ve wondered more and more if a reworking of our Release Criteria could help make parts of our decision process clearer and easier to follow.  By clearly defining our Target Audience we should be able to write more specific and accurate release criteria. The recent PackageKit controversy highlights this importance.  The settings for this package made certain assumptions about a particular target audience and user of Fedora.  It makes me wonder how many other parts of our distribution make different or contradictory assumptions about our target audience–resulting in a distribution that is not as coherent and consistent as it could be.

A clear definition of our target audience might also reduce the emphasis we place on developing and testing certain areas, freeing up time to make other things better.

How do you know when testing is done?  How do you know when the product is ready to release?  Does the decision to release seem similar to deals done in the dark, smoke-filled rooms, or as if there are rules of the game that you don’t know?  Does the release decision sometimes seem completely arbitrary?  If you’re finding it difficult to make rational decisions about when to release the software, developing and using release criteria can help–Johanna Rothman

I’ve been more or less actively involved in Fedora since Fedora 7.  Even though I’ve just completed my fifth release, am actively involved in creating the schedules, and lead the readiness meetings before each public test and final release, this paragraph still resonates with me.  This has long been one of my frustrations of trying to understand and participate in Fedora development process.  Things have definitely gotten better over the past few releases.  We can still do a better job without adding layers of bureaucracy which some people fear.

To move this process forward I took a first shot at an enhanced release criteria framework for Fedora 13.  Ultimately I believe we need a stronger framework to be more successful, but I’m not saying the framework I’ve proposed is the one we have to use.  A lot of the information included has been in existence for a long time at the QA Release Criteria page.  From it I created three separate pages–one for each public release: Alpha, Beta, and Final as well as an introductory page.   I also added a few extra proposed bullets.  I copied and pasted most of them from Release Criteria and adapted the ”shoulds” and ”musts” as specified–where ”must” was required for all releases and ”should” was only required for the final release.

I think a separate page for each release is helpful because in reality each release has a separate target audience.  The audience and goals for the Alpha release are much different than the audience and goals for the Final release. Certainly there will be overlap in these audiences, but we sell ourselves short if we assume the audience and goals for all three releases are the same.  My hunch is that some of these requirements are dated and wrong which makes reviewing everything for Fedora 13 a good thing.  In light of the security discussion around PackgeKit we may also want to add a security aspect to our release criteria.

Another benefit of a clear list of release requirements is that the “Go/No-Go” meetings become more objective.  There is less of a need to subjectively take everyone’s pulse and ask people how they are feeling.  Instead we review the list of release requirements, which also encompasses blocker bugs.  If the requirements are met we ship.  If they are not met, we add a week the schedule and try again.  The definition of what makes a bug a release blocker becomes clearer as well.  In addition I’ve started a new blocker bug FAQ.

Check out the wiki pages and join in the discussion on fedora-test-list where I’ve started a thread on the same topic.  My hope is that we can refine and discuss these pages over the next two weeks and then meet at FUDCon in Toronto to discuss and put a framework in place for Fedora 13.