Open Stack

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

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

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