On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote:
On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
> ----- Original Message -----
>> On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller
>> <mattdm(a)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