Open Stack

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