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@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
