Open Stack

On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathews <dolph.mathews at 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 <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/0c45d88e/attachment.html>