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