Fedora planning process: features as packages vs feature as changes

Matthew Miller mattdm at fedoraproject.org
Mon Dec 10 19:04:09 UTC 2012


I took a look at the features for the past few releases, and noticed they
fall into about 40% completely new leaf features, 40% upgrades to things we
already have, and 20% or fewer "distro config changes". That is, not
necessarily new packages; rather plans to configure Fedora differently. (For
example: "Use tmpfs for /tmp" or "make firewalld the default".)

In line with Fedora's foundations, I think we should

a) Make the process for adding new "leaf" features even more lightweight.
   These are basically marketing points and if they don't make the schedule,
   no problem. They can even be added after a final release, but should be
   done by beta in order to make the release notes and marketing material.

b) Keep the process and schedule for upgrades about where it is: update done
   by beta freeze, tested during beta -- with enough time to activate any
   contingency plan and test *that* if the testing turns up big problems.
   
   Here is where the critical path concept would come in: the criteria for
   going forward should be weighted by impact. (And it'd be helpful to
   categorize features one way or the other as part of feature submission.)
   
c) Require testing of distro config changes a little bit earlier.
   Specifically, they should be complete at the alpha change deadline, and
   tested during the alpha, and rollback considered before the beta starts.

   This gives us time to back out potentially-wide-reaching changes and test
   with *that* configuration during the beta, so we're not scrambling during
   the final push. (Again, weighting this by critical path impact is
   sensible.) 
   
Unless a change is a fiasco and it's decided to completely undo the
decision, work would continue in Rawhide and would easily be ready for the
next release six months later.


adding new features lightweight (maybe make it even more lightweight). A




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>


More information about the devel mailing list