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

Panu Matilainen pmatilai at laiskiainen.org
Thu Nov 1 17:23:13 UTC 2012


On 11/01/2012 07:08 PM, Adam Williamson wrote:
> On Thu, 2012-11-01 at 09:56 -0400, Matthew Miller wrote:
>> On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote:
>>> There are features and features... some of them are new versions of
>>> leafnode packages or a just bunch of new packages which nothing else
>>> depends on, and some of them affect *everything* in the distro.
>>> Perhaps the invasive changes should have a considerably earlier
>>> deadline, and if the deadline is not met then the feature would be
>>> "automatically" postponed to next release.
>>
>> Right now, the Feature template has this sections:
>>
>>    == Scope ==
>>    <!-- What work do the developers have to accomplish to complete the feature
>>    in time for release?  Is it a large change affecting many parts of the
>>    distribution or is it a very isolated change? What are those changes?-->
>>
>> Maybe the explanation could be strengthened, and some "checkbox" options
>> added:
>>
>> Choose one of:
>>
>>   ☐ "This is a "leaf" feature adding new, stand-alone functionality.
>>
>>   ☐ This feature brings new functionality which changes the default user
>>     experience for many users.
>>
>>   ☐ This feature introduces changes which affect the user experience only in
>>     its own area.
>
> To make things clearer I think you could drop 'brings new functionality
> which' from the second checkbox. The key thing we're trying to isolate
> is whether the feature has implications for 'normal' usage; it doesn't
> matter whether it's introducing new functionality.
>
> I was rather thinking we can simply take advantage of the critical path
> definition here. After all, when we came up with the critpath, the idea
> was it was a general concept which could be useful beyond the idea of a
> 'critpath package'. So why don't we just introduce the concept of a
> 'critpath feature' - any feature with implications for the critical
> path?

Nod. The critical path package set would serve at least as a point for 
refining the feature process. What the actual implications of critpath 
feature would be, Debian-style earlier freeze and/or something else, is 
probably a whole another (no doubt lengthy) topic :)

	- Panu -


More information about the devel mailing list