----- Original Message ----- > 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. Well, at least a) is very similar to what we proposed [1]. Not sure b) and c) covers everything that need "classic" process. But could be added to the proposal as some kind of guidelines. [1] https://fedoraproject.org/wiki/User:Mmaslano/Feature_process Jaroslav > > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
