On 13.07.2016 10:09, Andreas Jaeger wrote: > On 2016-07-12 09:59, 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 >> >> 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 > > You could also use a specific topic for these - instead of the bug/XXX, > use TOP10BUG. > > Another suggestion: Check what neutron has done with their review board > that is available from http://status.openstack.org/reviews/ as "Gerrit > Dashboard links" - a dashboard that takes into account the launchpad bug > status and is generated using a script (see > https://review.openstack.org/298779 ), > > Andreas >
Yep, another possible way to support the idea by tooling. What's more important is the commitment of reviewers/authors I guess. If that commitment isn't there, tooling won't help. -- 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
