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@lists.launchpad.net (mailto: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
