Open Stack

On 12-07-16 09:59:12, Markus Zoeller wrote:
> After closing the old (>18months) bug reports nobody is working on a few
> days ago [1], it became clear that the "in progress" reports are the
> majority [2]. After asking Gerrit how long it usually takes to get a fix
> merged [3], this is the result:
> 
>     number of merged bug fixes within the last 365 days: 689
>     merged within ~1m : 409 (~59%)
>     merged within ~2m : 102 (~14%)
>     merged within ~3m :  57 (~ 8%)
>     merged > 3month   : 121 (~17%)
> 
>     Note: This doesn't reflect the time a patch might be marked as
>     "WIP". It also doesn't add up to 100% as I rounded down the
>     percentages.
> 
> This made me thinking about ways to increase the review throughput of
> bug fix changes, especially the bug fixes in the "~2m" and "~3m" area. I
> *assume* that the fixes in the ">3m" area had inherent problems or
> waited for basic structural changes, but that's just guesswork.
> 
> The proposal is this:
> * have a TBD list with max 10 items on it (see list possibilities below)
> * add new items during nova meeting if slots are free
> * Change owners must propose their changes as meeting agenda items
> * drop change from list in nova meeting if progress is not satisfying
> 
> List possibilities:
> 1) etherpad of doom? maintained by (?|me)
>     + easy to add/remove from everyone
>     - hard to query
> 2) gerrit: starred by (?|me)
>     + easy to add/remove from the list maintainer
>     + easy to query
>     - No additions/removals when the list maintainer is on vacation
> 3) gerrit: add a comment flag TOP10BUGFIX and DROPTOP10BUGFIX
>     + easy to add/remove from everyone
>     + easy to query (comment:TOP10BUGFIX not comment:DROPTOP10BUGFIX)
>     - once removed with a comment "DROPTOP10BUGFIX", a repeated
>       addition is not practical anymore.
> 4) gerrit: tag a change
>     + easy to add/remove from everyone
>     + easy to query
>     - not yet available in our setup
> 
> Personally I prefer 3, as it doesn't rely on a single person and the
> tooling is ready for that. It could be sufficient until one of the next
> infra Gerrit updates brings us 4. I'd like to avoid 1+2.
> 
> My hope is, that a focused list helps us to get (few) things done faster
> and increase the overall velocity. Is this a feasible proposal from your
> point of view? Which concerns do you have?
> 
> References:
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/098792.html
> [2] http://45.55.105.55:3000/dashboard/db/openstack-bugs
> [3]
> https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py

Thanks for bringing this up Markus! IMHO tags against either in-progress
launchpad bugs and/or gerrit reviews would work best here.

Cheers,

Lee
-- 
Lee Yarwood
Senior Software Engineer
Red Hat

PGP : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76