[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Features Process



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]