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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
