On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathews <dolph.math...@gmail.com> wrote:
> 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 > Permalink: https://github.com/dolph/dotfiles/blob/2cf8cf21821a1014883c6669bd9886b38d0225ae/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 <mzoel...@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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >
__________________________________________________________________________ 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