openstack team mailing list archive

[John Postlethwait <john.postlethwait@xxxxxxxxxx>]

Really awesome stuff, thank you guys!

John Postlethwait
Nebula, Inc.
206-999-4492


On Thursday, June 7, 2012 at 3:46 PM, Monty Taylor wrote:

> 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@xxxxxxxxxxxxxxxxxxx (mailto:openstack@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
> 
>