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

Adam Williamson awilliam at redhat.com
Thu Nov 1 19:16:36 UTC 2012


On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote:
> On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> > ----- Original Message -----
> >> On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller
> >> <mattdm at fedoraproject.org> wrote:
> >> > On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
> >> >> > That sounds good. Maybe recast those ideas as three levels?
> >> >> >  - Critical Path Feature
> >> >> >  - Other Enhancement Feature
> >> >> >  - New Leaf Feature
> >> >> We were thinking with a few folks more about "Self contained
> >> >> feature"
> >> >> but yeah, there's a lack of real definition.
> >> >
> >> > I think "Leaf" is better than "Self contained", since it's unlikely
> >> > for the
> >> > feature to have zero outside dependencies. I think it'd be fine for
> >> > such a
> >> > feature to rely on small changes to existing packages (version
> >> > updates,
> >> > say).
> >>
> >> I'd argue that this isn't a "feature" ... otherwise we could
> >> advertise
> >> every version upgrade as feature.
> >> If it does not affect a large amount of users it is simply a version
> >> upgrade not a "fedora feature".
> >
> > The question is - how do you know if it affects large amount of users,
> > it's not an important one, without letting people know, there's such
> > feature?
> 
> Does a lot of other packages depend on it? -> Likely affects a lot of users.
> Is it installed by default or a commonly used application / package ?
> -> Likely affects a lot of users.
> Is it a new package that isn't intended to be installed by default? ->
> Probably does not affects a lot of users.
> ... etc.
> 
> So while there is no 100% accurate definition applying some common
> sense helps here.

Well. It's worth considering the underlying problem here, which we've
known about for a while: the feature process is overloaded. We use it
for multiple purposes.

In this thread we're mostly concerned with the aspects of the feature
process that deal with genuine technical / QA issues: are we doing well
enough at evaluating and overseeing features from a technical
perspective.

However, the feature process achieves other things too. The other
obvious big one is publicity/documentation: that's the reason all these
leaf features are made features at all, so they can be written up in our
announcements and documentation.

I think the direction we're driving here will actually address that
problem too; if we split features into 'critpath' and 'leaf' (and maybe
some other category/ies) we will be able to make the process more sane.
For 'leaf' features we can concentrate on the PR/documentation stuff and
we really don't have to worry too much about the technical / release
schedule side of things for those features.

So if we go down the road of categorizing features and do a good job of
it, I think that rather makes the issue of 'why are these little things
features at all?' go away. They'd be features simply for the PR, and we
could codify that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the devel mailing list