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

[Fabian Deutsch]

>  On Wed, Nov 28, 2012 at 09:39:03PM -0500, John Dulaney wrote:
>  > a feature, especially a crit path feature, is not ready for prime time. 
>  > Obviously, if a feature is not %100 by feature freeze, then it needs to be
>  > dropped. I would even venture to suggest that we include in the SOP
>  > something along the lines of "If feature is not 80% by point X (X being two
>  > weeks prior to freeze), then FESCo should at that point evaluate enacting
>  > the fall back."
>  
>  I don't think percent-complete is very helpful. The numbers are often
>  completely arbitrary, and even if they are actually accurate to that project
>  hard to compare in a relative sense. 80% of a small feature may be far
>  closer to complete than 99% of a major one.
>  
>  I like burndown charts. Low overhead, easily read, and generally more
>  concrete than guesses at percentage done. I wonder if there's a way we can
>  easily provide a widget in the wiki for keeping them up to date. This:
>
> http://joel.inpointform.net/software-development/burn-down-charts-tutoria...
>  has a decent Google Docs template, but we wouldn't want to make that
>  requirement for our process. 
I must say that the Ubuntu folks are distilling their bugzilla informations quite
well on http://status.ubuntu.com/ubuntu-raring/ .
The good thing about this solution is, that bugzilla is (AFAIK) used to track the
progress of a feature - and using bugzilla could be also a doable to track
our features.

- fabian

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

[Matthew Miller]

On Wed, Dec 05, 2012 at 08:19:15PM +0100, Fabian Deutsch wrote:
>  > I like burndown charts. Low overhead, easily read, and generally
> more
>  > concrete than guesses at percentage done. I wonder if there's a way we can
>  > easily provide a widget in the wiki for keeping them up to date. This:
>  >
> http://joel.inpointform.net/software-development/burn-down-charts-tutoria...
>  > has a decent Google Docs template, but we wouldn't want to make that
>  > requirement for our process.
>  
>  I must say that the Ubuntu folks are distilling their bugzilla
>  informations quite well on http://status.ubuntu.com/ubuntu-raring/ . The
>  good thing about this solution is, that bugzilla is (AFAIK) used to track
>  the progress of a feature - and using bugzilla could be also a doable to
>  track our features. 
Well, it's their launchpad bug tracker, not bugzilla. It's a great idea,
though. Anyone want to volunteer to write something that extracts data from
our bugzilla and presents it in this format? 

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.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

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

[Rahul Sundaram]

>  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.
>  
Yeah.  This makes sense.  Wiki for tracking isn't a bright idea really.
Even package wishlists could be converted into bug reports like Debian
does.

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

[Emmanuel Seyman]

* Rahul Sundaram [06/12/2012 00:39] :
>  Yeah.  This makes sense.  Wiki for tracking isn't a bright idea really. 
And the time-tracking is already built in to bugzilla so most of the code
needed is already written.

Emmanuel

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

[Panu Matilainen]

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 -

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

[Vít Ondruch]

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.


Vít

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 -

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

[Matthew Miller]

On Thu, Dec 06, 2012 at 11:50:01AM +0100, Vít Ondruch wrote:
>  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. 
This is the kind of overhead professional software engineers work with all
the time. :)

But in seriousness, back when I was running the BU Linux distribution, we
did this in our bugzilla for mass updates covering small amounts of work to
large numbers of packges, and it was actually really helpful. (We used a
custom script to bulk file the bugs.) The ones that are a piece of cake get
closed quickly, and for the rest you can track what's going on with those
packages and replacements and so on.

But, I don't think we'd mandate that rebuilds like you describe would *have*
to happen that way. There could simply be a single "rebuild all xxxxx
because yyyyyy for zzzzzz" bug covering all that work, with blockers spawned
from that for the tricky cases.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

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

[Matthew Miller]

On Thu, Dec 06, 2012 at 11:14:19AM +0200, Panu Matilainen wrote:
>  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 :) 
https://fedorahosted.org/fesco/ticket/979

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;