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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev