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