Open Stack

On 12.07.2016 17:39, Sahid Orentino Ferdjaoui wrote:
> 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.

I'm not sure if I understand the concerns correctly. The list
possibilities below seem to be easy to maintain. My assumption is, that
minimizing the "wait time" (reviewers wait for new patchsets OR change
owners wait for new reviews) can increase the throughput. It makes the
commitment of change owners and reviewers necessary though.
I don't think that the list needs specific ordering rules. As I want to
target bug fixes with this proposal, the ordering is given by the impact
of the bugs.

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

This could result in silo mentality and discussions why list A gets
preferred over list B. That's why I want to avoid having multiple lists.
It's about fixing issues in Nova, not fixing issues in
<your-favorite-area-here>.

> 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.

Changing the commit message creates a new patchset which triggers the
gate checks again, that's why I thought making comments with a keyword
which can be queried is less trouble.

> 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)
>>


-- 
Regards, Markus Zoeller (markus_z)