On 07/12/2016 01:59 AM, 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
What do we hope to gain from this? Is the hope that random developers will see this list and review the proposed patches? Or that nova-core developers will focus their attention on these issues?
Chris __________________________________________________________________________ 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
