Open Stack

This is actually something I've thought a lot about (focusing the
community's review efforts), and have experimented with various solutions
in the keystone community. I've built external solutions that have worked
fairly well, but my current preference is to take advantage of what's
already built into gerrit: starred reviews and dashboards.

For example, here is a dashboard of reviews in the keystone ecosystem
starred by any member of keystone-core that *you* have not reviewed
yourself (so you'll need to be logged into gerrit for this link to work):

  http://bit.ly/1GnOuqw [1]

In other words, it's a personalized review queue of things keystone-core
deems important.

The advantage I see to this approach over a new label is that the star
feature is already in the gerrit UI and so people already use it. But
broadly speaking, I'm not aware of anyone utilizing that data today as a
crowd sourced data point.

If you'd like to create your own version of this dashboard, here's the
gerrit-dash-creator config file for this dashboard:

  https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone

To customize it for yourself, you'd pretty much only need to edit the
[dashboard] section, and specifically the "foreach" value to reflect the
right collection of projects and group of reviewers. After that it's a
matter of using gerrit-dash-creator to produce the link:

  https://github.com/openstack/gerrit-dash-creator

I'd love to take this a couple steps further if people find the approach
valuable. I'd like to regularly recreate these links for every project
based on the latest *-core membership, and the latest set of projects in a
given community, publish them to permalinks, and share those permalinks
with code reviewers.

[1] unshortened
h*ttps://review.openstack.org/#/dashboard/?foreach=is%3Aopen+%252Downer%3Aself+%28project%3Aopenstack%252Dattic%2Fidentity%252Dapi+OR+project%3Aopenstack%2Fkeystone+OR+project%3Aopenstack%2Fkeystone%252Dspecs+OR+project%3Aopenstack%2Fkeystoneauth+OR+project%3Aopenstack%2Fkeystoneauth%252Dsaml2+OR+project%3Aopenstack%2Fkeystonemiddleware+OR+project%3Aopenstack%2Fpycadf+OR+project%3Aopenstack%2Fpython%252Dkeystoneclient%29+%28starredby%3Abknudson%40us.ibm.com+OR+starredby%3Adstanek%40dstanek.com+OR+starredby%3Adolph.mathews%40gmail.com+OR+starredby%3Ajamielennox%40redhat.com+OR+starredby%3Albragstad%40gmail.com+OR+starredby%3Aos.lcheng%40gmail.com+OR+starredby%3Amarek.denis%40cern.ch+OR+starredby%3Amorgan.fainberg%40gmail.com+OR+starredby%3Astevemar%40ca.ibm.com+OR+starredby%3Aayoung%40redhat.com+OR+starredby%3Aguang.yee%40hpe.com+OR+starredby%3Ahenryn%40linux.vnet.ibm.com%29&title=Priority+keystone+reviews&Needs+attention=%252Dlabel%3ACode%252DReview%3C%3D2%252cself+%252Dlabel%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&New=%252Dlabel%3ACode%252DReview%3C%3D2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B1=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B1+%252Dlabel%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B2=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&Pending+gating=label%3AVerified%3D%2B1%252cjenkins+label%3AWorkflow%2B1&Gating=%252Dlabel%3AVerified%3C%3D%252D1%252cjenkins+%252Dlabel%3AVerified%3E%3D%2B1%252cjenkins+label%3AWorkflow%2B1&Failed+gating=label%3AVerified%3C%3D%252D1%252cjenkins+label%3AWorkflow%2B1
<http://review.openstack.org/#/dashboard/?foreach=is%3Aopen+%252Downer%3Aself+%28project%3Aopenstack%252Dattic%2Fidentity%252Dapi+OR+project%3Aopenstack%2Fkeystone+OR+project%3Aopenstack%2Fkeystone%252Dspecs+OR+project%3Aopenstack%2Fkeystoneauth+OR+project%3Aopenstack%2Fkeystoneauth%252Dsaml2+OR+project%3Aopenstack%2Fkeystonemiddleware+OR+project%3Aopenstack%2Fpycadf+OR+project%3Aopenstack%2Fpython%252Dkeystoneclient%29+%28starredby%3Abknudson%40us.ibm.com+OR+starredby%3Adstanek%40dstanek.com+OR+starredby%3Adolph.mathews%40gmail.com+OR+starredby%3Ajamielennox%40redhat.com+OR+starredby%3Albragstad%40gmail.com+OR+starredby%3Aos.lcheng%40gmail.com+OR+starredby%3Amarek.denis%40cern.ch+OR+starredby%3Amorgan.fainberg%40gmail.com+OR+starredby%3Astevemar%40ca.ibm.com+OR+starredby%3Aayoung%40redhat.com+OR+starredby%3Aguang.yee%40hpe.com+OR+starredby%3Ahenryn%40linux.vnet.ibm.com%29&title=Priority+keystone+reviews&Needs+attention=%252Dlabel%3ACode%252DReview%3C%3D2%252cself+%252Dlabel%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&New=%252Dlabel%3ACode%252DReview%3C%3D2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B1=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B1+%252Dlabel%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B2=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&Pending+gating=label%3AVerified%3D%2B1%252cjenkins+label%3AWorkflow%2B1&Gating=%252Dlabel%3AVerified%3C%3D%252D1%252cjenkins+%252Dlabel%3AVerified%3E%3D%2B1%252cjenkins+label%3AWorkflow%2B1&Failed+gating=label%3AVerified%3C%3D%252D1%252cjenkins+label%3AWorkflow%2B1>*

On Tue, Oct 20, 2015 at 11:09 AM, Markus Zoeller <mzoeller at de.ibm.com>
wrote:

> In ML post [1] I wondered if it would be possible to introduce a new
> "prio" label in Gerrit which could help in focusing review efforts to
> increase the throughput. With this new post I'd like to discuss if we
> think this could be useful. For example, this would allow to create this
> query in Gerrit:
>
>     "status:open label:Prio=3"
>
> I was curious how this could look like in Gerrit, which resulted in the
> screenshots available at [2]. This would minimize the gap between the
> prio of the blueprints/bugs and their commit reviews.
>
> I'm mostly active in Nova, so here a short example of how we currently
> try to speed up the merges of trivial fixes:
>
> * contributor "A" spots a review which looks trivial
> * contributor "A" copies the review ID into an etherpad
> * core reviewer "B" reads the etherpad when possible
> * core reviewer "B" does a review too and eventually gives a +W
> * core reviewer "B" removes that review from the Etherpad when it merges
>
> This workflow is only necessary because Gerrit does not allow to
> categorize reviews, e.g. into a group of "trivial fixes".
>
> I noticed in my "mini poc" that it would be possible to set permissions
> to specific label values. Which allows us to have a "trivialfix" prio
> which can be set by everyone, but also a "high" prio which can be set
> by an automated entity which reuses the priority of the blueprint or
> bug report.
>
> Do you think this would speed things up? Or is this just nitpicking on
> an already good enough workflow?
>
> Regards,
> Markus Zoeller (markus_z)
>
> References:
> [1] ML; October 2015; "[infra] Upgrade to Gerrit 2.11":
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077130.html
> [2] images of a "demo" of having a prio label in Gerrit:
>     http://postimg.org/gallery/strofne2/
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151020/db8bc6fb/attachment-0001.html>