features and percentages [was Re: RFC: Feature process improvements]

[Panu Matilainen]

On 12/06/2012 12:50 PM, Vít Ondruch wrote:
> Dne 6.12.2012 10:14, Panu Matilainen napsal(a):
>> On 12/05/2012 09:38 PM, Matthew Miller wrote:
>>> One approach: a convention where each feature gets a tracking bug,
>>> and then
>>> various tasks can be marked as blocking that. *Then*, each release
>>> can have
>>> a tracking bug for accepted features themselves, and the tool to
>>> produce the
>>> chart can simply be pointed at that and follow the tree downward.
>>
>> Trackign them in bugzilla makes so much sense and seems so blatantly
>> obvious now that you said it... its kinda hard to understand why that
>> hasn't been done from the start. Please make it so :)
>>
>>     - Panu -
>>
>
> Don't think it makes more sense then the percentage in wiki. I remember
> migration from Ruby 1.8.7 to Ruby 1.9.3. We needed to adjust every ruby
> package in fedora and rebuild them. Some of them were piece of cake,
> some needed patches, other packages needed to be retired and some of
> them replaced. Not sure how could bugzilla provide better estimates.
> Even tracking of this issues in BZ would be significant overhead.

I dont see anybody suggesting tracking a feature requiring mass-rebuilds 
on single package level. If a feature requires substantial 
mass-rebuilds, then the mass-rebuild tracker might be *one* bug where 
the mass-rebuild progress is tracked, and on which the feature depends. 
And hard-to-resolve rebuilds which require significant extra work could 
be tracked in their own bugs which in turn block the main mass-rebuild 
bug. Or something like that.

As the current feature percentage meter means absolutely nothing at all, 
its kinda hard to do worse than that :)

	- Panu -