Fedora 9 Feature Policy Review
|This page is to track changes and discussion changes to the Fedora 9 feature process based on our experiences in F8. This is a public white board--everything is up for discussion.|
- Blog entry http://poelcat.wordpress.com/2007/10/16/fedora-8-feature-retrospective/
- Current policy http://fedoraproject.org/wiki/Features/Policy
- After FESCo discusses and votes on the new development process proposed by Jesse Keating, I would start a discussion culminating in a vote by FESCo one week from now (November 8) as to how we want the Feature process to work for Fedora 9.
1. What is a feature and how should the policy be clarified http://fedoraproject.org/wiki/Features/Policy#definition ?
- considering that anyone can commit new code and packages to Fedora what is unique about a feature?
- it is waste of everyone's time to have someone create a feature page and then for FESCo to say "denied--that isn't a feature"
1. Should there be different kinds of features? (mclasen)
- I think it is worth making it more explicit that there are different kinds of features. Something like "replace program a with program b" or "rewrite program c" (examples are esd -> pulseaudio, or NM) is very different from "gradually improve fedora wrt. to foo" (examples are better laptop support, less power consumption). For the former, it makes sense to have a contingency plan, which will usually be "stay with the old version". For the latter, it is fine to just do as much as you get done for this release, and continue improving the situation afterwards.
- For the gradual improvement type features, the main question at feature freeze time is if we have achieved enough of an improvement to make a big splash about it.
1. Do we have common agreement on the purpose of creating a feature page?
- release notes?
- developer synchronization if several people work on a feature?
- cross-distro and upstream communication?
- all of the above?
1. What if someone creates a nice enhancement to Fedora that is new in the upcoming release but no feature page is created for it? For example, system-config-firewall in F8. How do we incent people to create a feature page or does the Release Summary cover this case--if yes, how does content get collected for the Release Summary?
I get content for release notes from development and test list discussions, QA meetings, feature list, package change logs, release notes etc. The feature process has helped out a lot but a more well organized and complete feature list where all the important features are determined well ahead of any documentation freezes would definitely helps me more - RahulSundaram
1. How do we (realistically) encourage people to keep their feature pages up to date?
- It was a pain to keep hounding people to keep the status of their pages up to date--very few people kept them updated every 2 weeks.
- Considering how short our release cycle is I don't think we can go much longer than that.
Scheduling and hard decisions
1. What does "Feature Freeze" really mean?
- Do we want to be more disciplined? If we aren't truly feature frozen should we:
1. move the end of the schedule to allow adequate testing time? 1. drop the feature? 1. fire the feature wrangler? 1. put the feature owner on a short leash and require weekly updates to FESCo ?
- What is the point of having a milestone that we don't really follow?
- Does it matter if only a few features are truly done at Feature Freeze--do we drop the features that are not done and drive to GA?
- mclasen--This really depends on the type of feature; for the gradual features discussed about, dropping them is not very meaningful. For "replace existing functionality" or "new stuff" features, dropping could be a possibility, but looking at this at feature freeze time is really too late; if we want to be serious about dropping features, we need to do closer monitoring of features before the freeze, and ensure that the contingency plans are in place and that people are aware of the approaching freeze, and don't miss it by accident.
1. What if a feature is not complete at Feature Freeze?
- How do we decide to drop it versus give it more time?
1. How do we define complete? Does it mean:
- done enough?
- done enough to be tested?
- the traditional meaning of the word--"all done" (100%)?
1. Do we want to change the wording of this section: http://fedoraproject.org/wiki/Features/Policy#drop ?