Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Mon, Nov 5, 2012 at 8:38 PM, Matthew Miller <mattdm at fedoraproject.org> wrote:
> On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote:
>> > Here, I think you're smooshing together two of the three levels I'd
>> > suggested, putting both non-crit-path enhancements and new leaf
>> > functionality into one category. Is that correct?
>> Yes, the "self-contained" wording covers both leaf features and a
>> subset of non-leaf features.  "Non-crit-path" and "all relevant
>> maintainer are involved" are different subsets of non-leaf features,
>> however.
>
> From the point of view of evaluating impact, and for that matter for the
> release notes, I think it's good to have big-non-crit-path-enhancements and
> leaf functionality categorized separately. Both of them would need to be
> self contained in the sense you're suggesting.

Sure, the primary measure is the overall impact on the OS.  The
proposal is to treat "self-contained" features as "approved by
default", nothing more; features with large impact would still go
through the full process by overriding the default approval.

> In fact, for that matter, wouldn't crit path updates _also_ benefit from the
> "all relevant maintainers" rule?

A crit path update that affects, say, two packages and nothing else,
could be "approved by default" as well.  Many of the crit path
features however affect a large or extremely large package set (e.g.
the sysv->systemd script migration), in which case explicitly
involving every maintainer as the feature owner before even proposing
the feature wouldn't scale; that's where FESCo does need to step in as
a more efficient way to represent the large group of packagers.
    Mirek