Open Stack

On 13.07.2016 09:56, Sahid Orentino Ferdjaoui wrote:
> On Tue, Jul 12, 2016 at 06:45:03PM +0200, Markus Zoeller wrote:
>> 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.
> 
> How I see that you want to concentrate reviewers to be on 10 patches
> every weeks but here the bottleneck would be the authors, no?
> 
> I think we have a pretty good flow, most of the bug fixes which need
> to get attention are reviewed quickly.
> 

To be precise, the 10 patches on this list is just an upper bound. It is
*not* said that this should be merged within 1 week. *If* a new slot
gets freed because one of the changes merged, *then* a new change can be
added *if* the authors commit themselves to push new ps quickly.
By bringing the changes into the spotlight, there is a little pressure
to not be *that person* who stalls the flow.
I agree that the flow is already good. The numbers from above show that
almost 60% of the fixes merge within 4 weeks, which is good. Trying to
increase that is a good thing too, IMO.

>>> 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>.
> 
> I don't think that could result in silo mentality and I remember a
> initiative in the same way but with etherpad and so difficult to
> maitain.
> 

Yes, the etherpad is hard to maintain and makes the the review-workflow
a little more cumbersome IMO. What were the reasons the last initiative
didn't work out?

>>> 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.
> 
> Gerrit comments are lost when the patch get merged, we may want to
> provide some stats from these tags in future that's why I think commit
> message is better. Also if we only change commit messages, all of the
> gate is re-executed ?

Personally, after the patch got merged and the bug fixed, I don't have
any interest in it anymore. I don't want to spent efforts on things
which might never happen. Important fixes will have a reno as usual, so
users will be notified anyway.
IIRC, each new ps will result in a new gate check. But that's a
technical discussion which doesn't bring any benefit from my point of view.

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


-- 
Regards, Markus Zoeller (markus_z)