Re: [Openstack] Gerrit Workflow Changes
cor...@inaugust.com (James E. Blair) writes:
> Hi,
>
> Monty and I have been working on a solution to a number of problems
> and suggested enhancements to Gerrit. In short, we're planning on
> adding a new review type to Gerrit so that a core reviewer can
> specifically mark a review as "Approved" for Jenkins to test and
> merge. This will end our overloading of the "+2" code review for that
> purpose. We're planning on upgrading Jenkins and making these changes
> on Tuesday, December 27th.
This work is complete.
Here's what you (particularly core reviewers) need to know about
reviewing changes:
* Code review +2 votes will no longer trigger Jenkins.
* Core reviewers may now feel free to vote with any value between -2
and +2 on any change. They should vote +2 if they want their vote to
be counted as meeting the inclusion criteria of "positive reviews
from at least 2 core developers". Such votes from core reviewers are
now easily visible on the review page.
* To approve a change and start the merge process, core reviewers
should vote +1 in the "Approved" category (click the review button
again, and only change the value for the "Approved" category).
* Core reviewers should periodically scan for reviews that are ready
for approval and approve them if they feel they have been
sufficiently reviewed and the inclusion criteria are met.
* There is a new column, labeled "A", on all the pages where changes
are listed that corresponds to the "Approved" category ("V" and "R"
are "Verified" and "Code Review" respectively). That should help
make visible reviews that have at least one core reviewer but haven't
yet been approved.
Here is an example of what the votes for a review should look like now;
this review has 2 reviews from core reviewers, was then approved, and
then Jenkins verified the change and merged it:
https://review.openstack.org/#change,2287
Please contact me (jeblair) or Monty (mtaylor) on IRC if you run into a
problem or need any help with the new process.
Thanks,
Jim
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Gerrit Workflow Changes
Fantastic! I've been tired of having to look up people to see what their vote counted as. It's gotten hard to keep track of everyone. -tr3buchet On Tue, Dec 20, 2011 at 2:37 PM, Thierry Carrez wrote: > James E. Blair wrote: > > Monty and I have been working on a solution to a number of problems > > and suggested enhancements to Gerrit. In short, we're planning on > > adding a new review type to Gerrit so that a core reviewer can > > specifically mark a review as "Approved" for Jenkins to test and > > merge. This will end our overloading of the "+2" code review for that > > purpose. We're planning on upgrading Jenkins and making these changes > > on Tuesday, December 27th. Read below for our rationale, or skip to > > the end to see specifically what workflow will change. > > [...] > > Sounds all good to me. > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Gerrit Workflow Changes
James E. Blair wrote: > Monty and I have been working on a solution to a number of problems > and suggested enhancements to Gerrit. In short, we're planning on > adding a new review type to Gerrit so that a core reviewer can > specifically mark a review as "Approved" for Jenkins to test and > merge. This will end our overloading of the "+2" code review for that > purpose. We're planning on upgrading Jenkins and making these changes > on Tuesday, December 27th. Read below for our rationale, or skip to > the end to see specifically what workflow will change. > [...] Sounds all good to me. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Gerrit Workflow Changes
Hi, Monty and I have been working on a solution to a number of problems and suggested enhancements to Gerrit. In short, we're planning on adding a new review type to Gerrit so that a core reviewer can specifically mark a review as "Approved" for Jenkins to test and merge. This will end our overloading of the "+2" code review for that purpose. We're planning on upgrading Jenkins and making these changes on Tuesday, December 27th. Read below for our rationale, or skip to the end to see specifically what workflow will change. Rationale: One of the problems we want to solve is that it's difficult to see which votes are from project-core members (bug 900413). Even though with Gerrit ACLs only project-core members can vote code review +2, because we use that as the trigger for Jenkins jobs and ask core reviewers to vote +1 until the change is ready to go in, it's not obvious which votes are from core team members. By changing the Jenkins trigger to something else, the full range of values for code review votes is again available for use. Any number of core reviewers can vote +2, and their doing so indicates to anyone looking at the review that they are a core reviewer. A person looking to see if a patch has been sufficiently reviewed for inclusion can look for 2 +2 votes. A core reviewer who doesn't feel very strongly about his or her review can even vote +1 to say "I like this but I don't want my vote to count as a core reviewer vote". We're upgrading to a new version of the Gerrit Trigger plugin for Jenkins that allows the selection of different trigger criteria (for instance, when a patchset is uploaded or when a change is merged), and to that we're added a configurable trigger for when a vote is left for a review (bug 903375). Now that they are available, we will be using all of the above trigger types in Jenkins to make our job configuration model closer to what we want. Now that we have the ability to easily specify what Gerrit action should trigger a job in Jenkins, we will add a new review category to Gerrit called "Approved". Core reviewers (only) will be able to vote 0 or 1 in this category, and when they do so, the change will be considered approved, and Jenkins will immediately run trunk gating tests and merge the change on completion. It will also appear as a separate column on pages that list reviews (labeled "A", for "Approved", along with "V" for "Verified", and "R" for "Code Review"). This will make it easy to see which reviews have been approved, and which may or may not need to be approved. Proposed Workflow Changes: * Code review +2 votes will no longer trigger Jenkins. * Core reviewers may now feel free to vote with any value between -2 and +2 on any change. They should vote +2 if they want their vote to be counted as meeting the inclusion criteria of "positive reviews from at least 2 core developers". * Core reviewers should periodically scan for reviews that are ready for approval and approve them if they feel they have been sufficiently reviewed and the inclusion criteria are met. * To approve a change and start the merge process, core reviewers should vote +1 in the "Approved" category (click the review button again, and only change the value for the "Approved" category). * These changes will go into effect on Tuesday, December 27th. This wiki page has some screenshots of what the above changes will look like: http://wiki.openstack.org/GerritWorkflowChanges Thanks, Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
