Re: [openstack-dev] [infra][all] Reviews with a prio label?
Zaro <zaro0...@gmail.com> wrote on 10/20/2015 07:49:13 PM: > From: Zaro <zaro0...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 10/20/2015 07:54 PM > Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label? > > Upstream Gerrit has been working on a tagging feature for a while now. > Take a look at the gerrit discussion thread[1] if you want more info > on how it came about. They decided to call it 'hashtag' or '#' (the > name being very controversial).Looks like some of the feature is > in Gerrit 2.11 already[2] but it's definitely still work in progress > with sparse documentation thus far. I believe it should be fully > available in the 2.12 release and you can track it with > topic:hashtag[3] on upstream. > > [1] https://groups.google.com/d/msg/repo-discuss/-dHTaWt_LJA/JwUGeCPDpTUJ > and https://groups.google.com/d/msg/repo-discuss/jZ0raMyuiG0/YlntREKG0FgJ > [2] https://review-dev.openstack.org/Documentation/config- > hooks.html#_hashtags_changed > [3] https://gerrit-review.googlesource.com/#/q/topic:hashtags Thanks! I've searched for "labels", "tags" and "categorization". It would never have occured to me to search for "hashtag". I'll play around with my local Gerrit 2.11 installation and let you know about the results. Regards, Markus Zoeller (markus_z) __ 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
Re: [openstack-dev] [infra][all] Reviews with a prio label?
On 10/20/2015 12:43 PM, Dolph Mathews 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. The rally team uses it as part of their dashboard - https://github.com/stackforge/gerrit-dash-creator/blob/4d597f3b9c62f4422e3f8cdcd3b9c96921faa155/dashboards/rally.dash#L6-L7 > 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. One of the challenges you run into is url length limits in browsers, given that we're encoding the whole thing in the url. I do think the overall approach has a lot of merrit, though it would still be awesome if there was a more baked in tagging in gerrit. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [infra][all] Reviews with a prio label?
Upstream Gerrit has been working on a tagging feature for a while now. Take a look at the gerrit discussion thread[1] if you want more info on how it came about. They decided to call it 'hashtag' or '#' (the name being very controversial).Looks like some of the feature is in Gerrit 2.11 already[2] but it's definitely still work in progress with sparse documentation thus far. I believe it should be fully available in the 2.12 release and you can track it with topic:hashtag[3] on upstream. [1] https://groups.google.com/d/msg/repo-discuss/-dHTaWt_LJA/JwUGeCPDpTUJ and https://groups.google.com/d/msg/repo-discuss/jZ0raMyuiG0/YlntREKG0FgJ [2] https://review-dev.openstack.org/Documentation/config-hooks.html#_hashtags_changed [3] https://gerrit-review.googlesource.com/#/q/topic:hashtags On Tue, Oct 20, 2015 at 9:40 AM, Markus Zoeller <mzoel...@de.ibm.com> wrote: > "Daniel P. Berrange" <berra...@redhat.com> wrote on 10/20/2015 06:21:05 > PM: > >> From: "Daniel P. Berrange" <berra...@redhat.com> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: 10/20/2015 06:21 PM >> Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label? >> What you're describing is really just a special-case of allowing >> arbitrary user tagging of changes. If gerrit had a free-format >> keyword tag facility that users could use & query, it'd open up many >> possible options for improving our general workflow, and letting >> users customize their own workflow. >> >> Regards, >> Daniel > > True. My proposal is indeed a poor man's way of tagging. My research, > if Gerrit provides such a feature, didn't bring up any results. > > Regards, Markus Zoeller (markus_z) > > > __ > 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
Re: [openstack-dev] [infra][all] Reviews with a prio label?
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=Priority+keystone+reviews+attention=%252Dlabel%3ACode%252DReview%3C%3D2%252cself+%252Dlabel%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0=%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+gating=label%3AVerified%3D%2B1%252cjenkins+label%3AWorkflow%2B1=%252Dlabel%3AVerified%3C%3D%252D1%252cjenkins+%252Dlabel%3AVerified%3E%3D%2B1%252cjenkins+label%3AWorkflow%2B1+gating=label%3AVerified%3C%3D%252D1%252cjenkins+label%3AWorkflow%2B1
Re: [openstack-dev] [infra][all] Reviews with a prio label?
On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathewswrote: > 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=Priority+keystone+reviews+attention=%252Dlabel%3ACode%252DReview%3C%3D2%252cself+%252Dlabel%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0=%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+gating=label%3AVerified%3D%2B1%252cjenkins+label%3AWorkflow%2B1=%252Dlabel%3AVerified%3C%3D%252D1%252cjenkins+%252Dlabel%3AVerified%3E%3D%2B1%252cjenkins+label%3AWorkflow%2B1+gating=label%3AVerified%3C%3D%252D1%252cjenkins+label%3AWorkflow%2B1 >
Re: [openstack-dev] [infra][all] Reviews with a prio label?
On Tue, Oct 20, 2015 at 12:09 PM, Sean Daguewrote: > On 10/20/2015 12:43 PM, Dolph Mathews 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. > > The rally team uses it as part of their dashboard - > > https://github.com/stackforge/gerrit-dash-creator/blob/4d597f3b9c62f4422e3f8cdcd3b9c96921faa155/dashboards/rally.dash#L6-L7 > > > 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. > > One of the challenges you run into is url length limits in browsers, > given that we're encoding the whole thing in the url. > I haven't run into any issues yet myself, but yes, definitely. One of the easiest changes I'd make to "compress" the URL is to use user IDs instead of emails like I did here, e.g.: https://review.openstack.org/#/q/status:open+starredby:4,n,z > > I do think the overall approach has a lot of merrit, though it would > still be awesome if there was a more baked in tagging in gerrit. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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
Re: [openstack-dev] [infra][all] Reviews with a prio label?
On Tue, Oct 20, 2015 at 06:09:51PM +0200, Markus Zoeller 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? What you're describing is really just a special-case of allowing arbitrary user tagging of changes. If gerrit had a free-format keyword tag facility that users could use & query, it'd open up many possible options for improving our general workflow, and letting users customize their own workflow. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
Re: [openstack-dev] [infra][all] Reviews with a prio label?
"Daniel P. Berrange" <berra...@redhat.com> wrote on 10/20/2015 06:21:05 PM: > From: "Daniel P. Berrange" <berra...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 10/20/2015 06:21 PM > Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label? > What you're describing is really just a special-case of allowing > arbitrary user tagging of changes. If gerrit had a free-format > keyword tag facility that users could use & query, it'd open up many > possible options for improving our general workflow, and letting > users customize their own workflow. > > Regards, > Daniel True. My proposal is indeed a poor man's way of tagging. My research, if Gerrit provides such a feature, didn't bring up any results. Regards, Markus Zoeller (markus_z) __ 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-dev] [infra][all] Reviews with a prio label?
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