On 12-07-16 09:59:12, 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 > > 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
Thanks for bringing this up Markus! IMHO tags against either in-progress launchpad bugs and/or gerrit reviews would work best here. Cheers, Lee -- Lee Yarwood Senior Software Engineer Red Hat PGP : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 __________________________________________________________________________ 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