Hey guys! We just upgraded to a new version of gerrit. This is based on the new upstream version 2.4, but in addition we've landed two additional features on top of that - so there's tons of new toys to play with.
First of all, in 2.4 upstream has added a new button "Rebase Change" ... which you can use to rebase your change on top of the current tip of the target branch from within gerrit itself. Also, upstream has been working on adding a proper REST interface, instead of json-rpc which is what they have been using. I'm not sure how far that's gotten, but I believe it can do a decent amount of stuff for those of you who like, you know, REST-based scripting. In addition to that, we've got two main features we've landed as well. David Shrewsbury wrote a long-requested feature: a Work In Progress state. Changes will now have a Work In Progress button on them that can be used to mark the change as something that the dev is working on again, so that other folks know they don't need to review it. The button is available to the author of the patch, as well any group that we assign to have access. In our case, we'll be granting $project-core Work In Progress permission. Putting something back into the "ready for review" state can be done one of two ways - either by just uploading a new patch to the change, or by clicking the "Ready for Review" button. Hand in hand with that change, Clark Boylan has written an "Important Changes" view - which shows all on one page the changes that a developer should be looking at. On the page are changes that were uploaded by the developer (same as the "My Changes" page), then a section for changes that the developer should be reviewing, which are changes that the dev has either watched, starred, or that reviews have been requested, and that are no in work in progress state and additionally that the dev has not already reviewed. Finally, there is a section for changes that the developer has already reviewed, in case they need to be further tracked. We're hoping that some of these things help to reduce a little bit of the burden in terms of tracking which things should be watched. We'll be working on getting our patches upstreamed in the near future... but since they are new workflow possibilities, we're happy to get feedback on ways in which they could be more useful to folks. Also - we have an open question - which is, if the pre-approval check jobs fail in Jenkins, should the patch be automatically marked Work In Progress. We're not going to do that right out of the gate, but would love feedback on what people think. Thanks everybody! Monty _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
