Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

Vít Ondruch vondruch at redhat.com
Fri Dec 7 11:13:32 UTC 2012


Dne 7.12.2012 11:13, "Jóhann B. Guðmundsson" napsal(a):
> On 12/07/2012 09:28 AM, Vít Ondruch wrote:
>>
>> Feature is something somebody considers important enough to create 
>> feature page for it. Period.
>
> That describes the current state and is your point of view.
>
> To me an "Feature" is a completely different thing.

Could you be more specific please?

>
>>
>> I am not sure why do you want to categorize it by size and impact, 
>> when it will be autocategorized by feedback on ML. 
>
> It's common knowledge that you cant autocategorized by feedback on 
> Mailing list regardless what's it's for. ( For obvious reasons )

They are probably not so obvious to me. But I can imagine several types 
of responses on ML:

1) No response at all. This is positive, since the feature was probably 
discussed on different places previously, such as SIG ML or is 
non-controversial.
2) Positive response. Everybody probably agrees that Gnome 3 should be 
updated in next release.
3) Controversial feature, such as /tmp on tmpfs
4) Only negative feedback. E.g. lets move to yet another init system.
5) WTF feedback. Why are you even proposing this minor update of this 
unknown library as a feature (but this is non-category, since it will be 
probably rejected by Package Wrangler already)?

These are 5 categories of features I can imagine. Now please tell me if 
the categorization is not clear and if that is not obvious how to 
proceed with these.

>
>> The only think matters is that the Feature is widely advertised and 
>> that the community can provide early feedback. 
>
> No that is not enough because in the end you will only get feedback 
> from users of those feature not necessary from developers of other 
> components that might get affected by that feature.

Yes, nobody never cares until it is not late. I can't change that. But 
I'm trying. Announcing features in devel/devel-announce is definitely 
step in good direction.

>
>> Please avoid bureaucracy. I would realy hate to see something like 
>> FFCo (Fedora Feature Committee), which would decided if feature is 
>> feature, major change, alteration, evolution or disruption, since it 
>> really doesn't matter.
>
> FESCO is for that, as in to accept,decide and determine the wider 
> impact an feature might have to the whole projects eco system and 
> arguably the entity that's responsible for it to be integrated into 
> the distribution in as painless manner for users and developers alike. 
> ( from my pov ).

FESCo's responsibilities does not change at all. The benefit will be 
that FESCo will be able to spent more time paying attention to features 
that are worth of attention. Don't forget that this discussion is 
initiative of FESCo members, who feels to be overwhelmed by 
non-important features, not mine.


Vít


More information about the devel mailing list