Fedora planning process: features as packages vs feature as changes
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(a)fedoraproject.org>