Fedora Features Process

[Christopher Aillon]

John Poelstra wrote:
> Based on 
> https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.html 
> 
> 
> I have drafted a proposed Feature process.  I submitted it to the Fedora 
> Board for a first pass via the wiki page (see inline comments).  Now I 
> am submitting it for additional public review and would like to have it 
> discussed and ratified at the next FESCo meeting.


We need a much better definition of what a feature is.  For one, 
features don't delay the release.  For another, things noteworthy enough 
to call out in the release notes is extremely vague.  What I might find 
noteworthy, others might scoff at.  Or vice versa.

Further reading the "Definition of a Feature" section, it appears to me 
that we're trying to answer the question of "Will feature X be in Fedora 
Y?"  This seems to me to be a broken question by design.  We are on 
date-driven release cycles, not feature-driven.  Work slips.  It 
happens.  Engineering priorities may shift, personal emergencies may 
occur, the person working on it in his free time may have less free time 
than anticipated, maybe someone is busy fixing bugs from the previous 
release.  Who knows?  There are many reasons why we can't answer this 
question as long as we are on a date-driven cycle.  (After the feature 
freeze, we can though).

The engineering cycle is rather short as it is with the freezes.  Rather 
than take time away from engineering the features that we want to get 
in, why not simply defer gathering this info until after the feature 
freeze as we do now?  The information gathered will be much more 
accurate than basing our information off volatile plans during a hard 
date-driven cycle.