At today's FESCo meeting, the final schedule for Fedora 11 was
approved. Now it's time for some reminders about the feature process
for Fedora 11. We're changing a few things this time around to
hopefully make the whole process run smoother than ever!
First., FESCo will be making decisions regarding dropping incomplete
features at the meeting *2 weeks before* the freeze date, in order to
give rel-eng and QA time to implement whatever contingency plans might
be required prior to the freeze. For Fedora 11, these dates are:
Alpha freeze: 1/20 - FESCo meeting - 1/8
Beta Freeze: 3/10 - FESCo meeting - 2/25
Final Freeze: 4/14 - FESCo meeting - 4/1
Also, note that feature freeze is on 3/3, a week prior to the Beta
freeze. This was done in order to provide more time for testing
between feature freeze and beta freeze, and fix any issues that come
up without having to break the beta freeze.
By the time of the Alpha freeze, features must have a defined
specification (i.e. the scope section of the template must be
complete). This should include criteria of what is required in order
to declare the feature a "success", for example, you're able to adjust
the volume in a variety of ways (name those ways) and that they have
the desired effect for the VolumeControl feature currently scheduled
By the time of the beta freeze, features must have a complete test
plan, and be in a testable state. A test plan is NOT simply "use it
and see if it works". Steps that can be reproduced by someone that has
little to no knowledge of your feature area, but a basic
understanding of Fedora and the command line, etc. is what's required
here. Taking the VolumeControl feature, there should be instructions
that tell me what packages need to be installed, what they're expected
to do under various circumstances, and how to make them do those
By final freeze, obviously the feature must be fully implemented and
ready to go out the door.
Also, as feature owners have features that are nearing completion, I
would encourage them to contact either myself or James Laska in order
to schedule a "test day" for that feature. In the past, these have
been incredibly successful in getting test coverage and exposure for
features that may not otherwise get it. The earlier in the process
that this can happen, the better.
I will be handling the QA items that are new to this release, John
Poelstra will continue in his role as the overall Feature Wrangler.
All of this is designed to ensure a high-quality release, and
minimize any schedule slips.
Show replies by date