Re: [Openstack] new version of gerrit - with new features!
Chmouel Boudjnah wrote: >> 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 > > So the difference between WIP and Draft is one is public and the other > is not, right? That's my understanding. I agree that the naming is quite confusing... Renaming "Drafts" to "Private" would probably be a more accurate description. >> 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. > > I think that a reasonable assumption to say that if the commit didn't > pass the tests there is still work to do in there and be marked as > such. In an ideal world yes... But with the amount of false negatives we have in jenkins tests, having test failures drop below the radar line might not be the best idea (yet). -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] new version of gerrit - with new features!
On Fri, Jun 8, 2012 at 12:46 AM, 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. Really cool, Thanks. > 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 So the difference between WIP and Draft is one is public and the other is not, right? > 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. I think that a reasonable assumption to say that if the commit didn't pass the tests there is still work to do in there and be marked as such. Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] new version of gerrit - with new features!
Fantastic. Aye to the holy "Rebase change" feature Nuage & Co - Razique Mahroua razique.mahr...@gmail.com Le 8 juin 2012 à 09:46, John Postlethwait a écrit : Really awesome stuff, thank you guys!John PostlethwaitNebula, Inc.206-999-4492On 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 newupstream version 2.4, but in addition we've landed two additionalfeatures 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 thetarget branch from within gerrit itself. Also, upstream has been workingon adding a proper REST interface, instead of json-rpc which is whatthey have been using. I'm not sure how far that's gotten, but I believeit 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 Progressstate. Changes will now have a Work In Progress button on them that canbe used to mark the change as something that the dev is working onagain, so that other folks know they don't need to review it. The buttonis available to the author of the patch, as well any group that weassign to have access. In our case, we'll be granting $project-core WorkIn Progress permission. Putting something back into the "ready forreview" state can be done one of two ways - either by just uploading anew patch to the change, or by clicking the "Ready for Review" button.Hand in hand with that change, Clark Boylan has written an "ImportantChanges" view - which shows all on one page the changes that a developershould be looking at. On the page are changes that were uploaded by thedeveloper (same as the "My Changes" page), then a section for changesthat the developer should be reviewing, which are changes that the devhas either watched, starred, or that reviews have been requested, andthat are no in work in progress state and additionally that the dev hasnot already reviewed. Finally, there is a section for changes that thedeveloper 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 ofthe burden in terms of tracking which things should be watched. We'll beworking on getting our patches upstreamed in the near future... butsince they are new workflow possibilities, we're happy to get feedbackon ways in which they could be more useful to folks.Also - we have an open question - which is, if the pre-approval checkjobs fail in Jenkins, should the patch be automatically marked Work InProgress. We're not going to do that right out of the gate, but wouldlove feedback on what people think.Thanks everybody!Monty___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help : https://help.launchpad.net/ListHelp ___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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
Re: [Openstack] new version of gerrit - with new features!
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
[Openstack] new version of gerrit - with new features!
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
