Fedora planning process: features as packages vs feature as changes

[Jaroslav Reznik]

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