razique.mahroua at gmail
Jun 8, 2012, 12:56 AM
Post #3 of 5
(188 views)
Permalink
|
|
Re: new version of gerrit - with new features!
[In reply to]
|
|
Fantastic.
Aye to the holy "Rebase change" feature
Nuage & Co - Razique Mahroua
razique.mahroua [at] gmail
Le 8 juin 2012 à 09:46, John Postlethwait a écrit :
> 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 [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
|
NUAGECO-LOGO-Fblan_petit.jpg
