On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote: > On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik <jreznik@xxxxxxxxxx> wrote: > > ----- Original Message ----- > >> On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller > >> <mattdm@xxxxxxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
