Open Stack

We discussed the possible technical solutions but didn't get attention
if we see the need to do that. As none of the core reviewers or subteam
leaders reacted to the proposal, I conclude that this is not an issue
where we need to put our limited resources at.
This post is just informational to bring the discussion to a conclusion.

-- 
Regards, Markus Zoeller (markus_z)


On 12.07.2016 09:59, 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
> 
>