<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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):</div><div><br></div><div> <a href="http://bit.ly/1GnOuqw" target="_blank">http://bit.ly/1GnOuqw</a> [1]<br></div><div><br></div><div>In other words, it's a personalized review queue of things keystone-core deems important.</div><div><br></div><div>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.</div><div><br></div><div>If you'd like to create your own version of this dashboard, here's the gerrit-dash-creator config file for this dashboard:</div><div><br></div><div> <a href="https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone" target="_blank">https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone</a></div></div></blockquote><div><br></div><div>Permalink: <a href="https://github.com/dolph/dotfiles/blob/2cf8cf21821a1014883c6669bd9886b38d0225ae/gerrit-dashboard-keystone">https://github.com/dolph/dotfiles/blob/2cf8cf21821a1014883c6669bd9886b38d0225ae/gerrit-dashboard-keystone</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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:</div><div><br></div><div> <a href="https://github.com/openstack/gerrit-dash-creator" target="_blank">https://github.com/openstack/gerrit-dash-creator</a></div><div><br></div><div>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.</div><div><br></div><div>[1] unshortened h<b>ttps://<a href="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" target="_blank">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</a></b></div>
</div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 11:09 AM, Markus Zoeller <span dir="ltr"><<a href="mailto:mzoeller@de.ibm.com" target="_blank">mzoeller@de.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In ML post [1] I wondered if it would be possible to introduce a new<br>
"prio" label in Gerrit which could help in focusing review efforts to<br>
increase the throughput. With this new post I'd like to discuss if we<br>
think this could be useful. For example, this would allow to create this<br>
query in Gerrit:<br>
<br>
"status:open label:Prio=3"<br>
<br>
I was curious how this could look like in Gerrit, which resulted in the<br>
screenshots available at [2]. This would minimize the gap between the<br>
prio of the blueprints/bugs and their commit reviews.<br>
<br>
I'm mostly active in Nova, so here a short example of how we currently<br>
try to speed up the merges of trivial fixes:<br>
<br>
* contributor "A" spots a review which looks trivial<br>
* contributor "A" copies the review ID into an etherpad<br>
* core reviewer "B" reads the etherpad when possible<br>
* core reviewer "B" does a review too and eventually gives a +W<br>
* core reviewer "B" removes that review from the Etherpad when it merges<br>
<br>
This workflow is only necessary because Gerrit does not allow to<br>
categorize reviews, e.g. into a group of "trivial fixes".<br>
<br>
I noticed in my "mini poc" that it would be possible to set permissions<br>
to specific label values. Which allows us to have a "trivialfix" prio<br>
which can be set by everyone, but also a "high" prio which can be set<br>
by an automated entity which reuses the priority of the blueprint or<br>
bug report.<br>
<br>
Do you think this would speed things up? Or is this just nitpicking on<br>
an already good enough workflow?<br>
<br>
Regards,<br>
Markus Zoeller (markus_z)<br>
<br>
References:<br>
[1] ML; October 2015; "[infra] Upgrade to Gerrit 2.11":<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-October/077130.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-October/077130.html</a><br>
[2] images of a "demo" of having a prio label in Gerrit:<br>
<a href="http://postimg.org/gallery/strofne2/" rel="noreferrer" target="_blank">http://postimg.org/gallery/strofne2/</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>