Open Stack

On Tue, Jul 12, 2016 at 09:59:12AM +0200, 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

Considering a raw list of patches would be difficult to maintain, it's
time consuming and Nova has contributors working on different areas
which are sometimes really differents. How to order this list and how
to consider a patch is satisfying the progress policy.

To make things working we should find some automations and have one
list by areas which is probably the purpose of tags in gerrit.

Since we don't have such feature on our gerrit yet, a possible
solution would be to introduce a tag in commit messages which reflects
the subteam or area related. Then a simple script could parse reviews
in progress to print them somewhere.

So each subteams can have a view of the work in progress which could
make things moving faster.

The point would be to order the lists by importance but we can expect
the lists relatively small.

> 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
> 
> 
> -- 
> Regards, Markus Zoeller (markus_z)
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev