From Fedora Project Wiki
< Features
Fedora 11 Feature Policy Review
| This page is to track changes and discussion changes to the Fedora 11 feature process based on our experiences during Fedora 10 development. This is a public white board--everything is up for discussion. |
Background
- Current policy http://fedoraproject.org/wiki/Features/Policy
- Features/F10PolicyReview
- Features/F9PolicyReview
Proposal
- Please start a new section for processes or policies that you would like to be different during the Fedora 11 feature process
- We will collect the ideas here from November 4, 2008 through November 11, 2008.
- I will propose that FESCo review the proposed changes to the policy at their meeting on November 12, 2008
Invite Feature owners to FESCo meetings
- Feature owners need to get an invitation to the FESCo meeting when their feature will be discussed.
- posting the FESCo schedule to fedora-devel isn't sufficient as that's a high traffic list and it is to easy to miss the schedule
- Having the feature owners in the meeting can speed things up a lot as questions can be asked and answered without one week delay between the meetings
- This would seem to be key -- adequate prior notice of the meeting should be given directly to the feature owner (direct email, IRC ping, bug, whatever) so they both know when to attend and have the necessary lead time to adjust their schedule to make it, if needs be. Chris Weyl 16:55, 10 November 2008 (UTC)
Stick to the process
In F10, we have seen both late additions (AMQP) and late removals (empathy). This further reduced the buy-in to the feature process. Why bother, if it all gets undone in last-minute FESCo decisions anyway ?
Miscellaneous
- It would be good if even minor version updates were at least recorded, and all feature changes organized or tagged along "beat" lines so that beat writers have a prayer -- Jjmcd
- There are both good and bad examples of how to articulate features. Perhaps those feature owners who are prose-challenged could have a writer assigned to maintain the feature page. -- Jjmcd
- Feature owners should always be CC'd on any announcements and meetings. -- rjones
- What is the point of sending out an meeting agenda and having a meeting summary, if no one bothers to read them? - bpepple
- I don't think it's unreasonable for people who don't serve on FESCo to not read the agenda or minutes. Poking those who own features before their feature is discussed both helps make sure they're there, and saves FESCo's time by making sure all the stakeholders are present. Chris Weyl 02:33, 12 November 2008 (UTC)
- And I don't think it's unreasonable for Feature owners to read 2 emails (agenda & summary) a week. If it's a problem of the e-mails being sent to a mailing list with too high of volume, we should look at them being sent to a lower-volume list (devel-announce), not adding an additional burden/responsibility to an already pretty thankless task. - bpepple
- What is the point of sending out an meeting agenda and having a meeting summary, if no one bothers to read them? - bpepple
Out of Scope
- It would be nice if we could choose between Amarok or Rhythmbox, during the instalation
- Integration of DNSSEC keys for resolving nameservers (named & unbound) with easy method of enabling/disabling. Working on a package for this, should be up for testing before Nov 14. Based on F10 experience decide to make it default or not. -- pwouters
Unified 32 and 64 bit installation media
I would be glad if there will be only one installation media (something as we have now for x86_64). The user then will pick pure 32 or 64 or mixed 32+64 bit environment installation. Milankerslager 07:44, 27 November 2008 (UTC)