Re: Github Reviews vs Reviewboard

On 25 October 2016 at 10:55, Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > roger peppe writes: > > > I think that review history is crucial for context on historic > > code decisions > > I wonder if we could hack a script to save the reviews as git

Re: Github Reviews vs Reviewboard

roger peppe writes: > I think that review history is crucial for context on historic > code decisions I wonder if we could hack a script to save the reviews as git notes, e.g. https://github.com/google/git-appraise With git's ability to rewrite history, I bet this

Re: Github Reviews vs Reviewboard

On 25 October 2016 at 10:17, Horacio Duran wrote: > Shouldn't we leave it for historic purposes? > > ​Will it really get used? My bet is that the project's commit history will be enough.​ -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or

Re: Github Reviews vs Reviewboard

Shouldn't we leave it for historic purposes? On Monday, 24 October 2016, Menno Smits <menno.sm...@canonical.com> wrote: > The votes are in: Github 8, Reviewboard 5. It looks like we stick with > Github Reviews. > > I'm going to email some people now about tearing down the Revi

Re: Github Reviews vs Reviewboard

The votes are in: Github 8, Reviewboard 5. It looks like we stick with Github Reviews. I'm going to email some people now about tearing down the Reviewboard instance. On 15 October 2016 at 06:57, Casey Marshall <casey.marsh...@canonical.com> wrote: > +1, as I work on many other Github

Re: Github Reviews vs Reviewboard

+1, as I work on many other Github projects besides Juju and it's familiar. It's not perfect by any means but I can work with it. I thought the ReviewBoard we had was pretty ugly and buggy, but it was reasonably easy to use. Gerrit is cleaner and clearer to me -- though I feel like Gerrit is also

Re: Github Reviews vs Reviewboard

On 14 October 2016 at 16:26, Mick Gregg wrote: > I would probably chose gerrit over either, but that's not the question > today. > Oooh, yes to gerrit. +2 -- Andrew McDermott Juju Core Sapphire team --

Re: Github Reviews vs Reviewboard

wrote: > -1000 :-) > > On 14/10/16 08:44, Menno Smits wrote: > > We've been trialling Github Reviews for some time now and it's time to > > decide whether we stick with it or go back to Reviewboard. > > > > We're going to have a vote. If you have an opinion on t

Re: Github Reviews vs Reviewboard

+1 to Github, I prefer the papercuts of githubs to the swordcuts from > reviewboard. > > On Fri, Oct 14, 2016 at 12:09 PM, Dimiter Naydenov < > dimiter.nayde...@canonical.com> wrote: > > > +1, Nate said what I was thinking :) > > > > On 10/14/2016 05:34 PM, Nate

Re: Github Reviews vs Reviewboard

every single PR. > > Reviewboard and related infrastructure breaks like once couple weeks, > and I'm not convinced it'll get better, since we've been using it for > quite some time now. > > I have missed exactly zero of the features of reviewboard since using > github, and have

Re: Github Reviews vs Reviewboard

+1 to Github, I prefer the papercuts of githubs to the swordcuts from reviewboard. On Fri, Oct 14, 2016 at 12:09 PM, Dimiter Naydenov < dimiter.nayde...@canonical.com> wrote: > +1, Nate said what I was thinking :) > > On 10/14/2016 05:34 PM, Nate Finch wrote: > > +1 &

Re: Github Reviews vs Reviewboard

[from canonical email address this time] On 14 October 2016 at 12:45, Adam Collard <adam.coll...@canonical.com> wrote: > Not sure I get a vote, but -1 > > You're running an old version of ReviewBoard (2.0.12 released in January > 2015) and many of the issues I think you've been

Re: Github Reviews vs Reviewboard

On 14 October 2016 at 12:45, Adam Collard <adam.coll...@canonical.com> wrote: > Not sure I get a vote, but -1 > > You're running an old version of ReviewBoard (2.0.12 released in January > 2015) and many of the issues I think you've been hitting are fixed in later > rev

Re: Github Reviews vs Reviewboard

Not sure I get a vote, but -1 You're running an old version of ReviewBoard (2.0.12 released in January 2015) and many of the issues I think you've been hitting are fixed in later revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and brings a chunk of new UI improvements

Re: Github Reviews vs Reviewboard

0 On 13/10/16 23:44, Menno Smits wrote: We've been trialling Github Reviews for some time now and it's time to decide whether we stick with it or go back to Reviewboard. We're going to have a vote. If you have an opinion on the issue please reply to this email with a +1, 0 or -1, optionally

Re: Github Reviews vs Reviewboard

+1. Although github reviews are by no means perfect, reviewboard is worse. It loses draft comments if you click in the wrong place; it takes two page reloads to be able to reply to a comment; it doesn't work well on mobile platforms; it doesn't understand file renames, and the comments

Re: Github Reviews vs Reviewboard

> > Tim > > On 14/10/16 11:44, Menno Smits wrote: >> >> We've been trialling Github Reviews for some time now and it's time to >> decide whether we stick with it or go back to Reviewboard. >> >> We're going to have a vote. If you have an opinion o

Re: Github Reviews vs Reviewboard

and it's time to decide whether we stick with it or go back to Reviewboard. We're going to have a vote. If you have an opinion on the issue please reply to this email with a +1, 0 or -1, optionally followed by any further thoughts. * +1 means you prefer Github Reviews * -1 means you prefer

Re: Github Reviews vs Reviewboard

her we stick with it or go back to Reviewboard. > > We're going to have a vote. If you have an opinion on the issue please > reply to this email with a +1, 0 or -1, optionally followed by any further > thoughts. > >- +1 means you prefer Github Reviews >- -1 means you prefer Rev

Re: Github Reviews vs Reviewboard

-1000 :-) On 14/10/16 08:44, Menno Smits wrote: > We've been trialling Github Reviews for some time now and it's time to > decide whether we stick with it or go back to Reviewboard. > > We're going to have a vote. If you have an opinion on the

Github Reviews vs Reviewboard

We've been trialling Github Reviews for some time now and it's time to decide whether we stick with it or go back to Reviewboard. We're going to have a vote. If you have an opinion on the issue please reply to this email with a +1, 0 or -1, optionally followed by any further thoughts. - +1

using the reviewboard dashboard effectively

I realized today that some folks may not be aware of some of the helpful columns in the reviewboard dashboard. You can see the full list of available columns by clicking on the pencil icon on the right. There are a handful of columns that I've found really helpful to me as a reviewer. Most

Reviewboard - dependant branches

the automatic reviewboard integration 2. run some rbt command line invocation to update reviewboard with the upstream branch name I just don't recall the exact invocation for #2 and I don't want to experiment and muck something up :) Cheers, -- John Weldon -- Juju-dev mailing list Juju-dev

Re: Reviewboard - dependant branches

the branch in github, which will trigger the automatic reviewboard integration 2. run some rbt command line invocation to update reviewboard with the upstream branch name I just don't recall the exact invocation for #2 and I don't want to experiment and muck something up :) rbt post -u --parent

Re: reviewboard update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15.11.2014 07:07, Eric Snow wrote: FYI, I was able to solve 3 reviewboard-github integration issues today: 1. pull requests for branches other than master now work (e.g. 1.21 backports) 2. no more hitting rate limits (5000 requests/hour limit

Re: reviewboard update

On Mon, Nov 17, 2014 at 5:10 AM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: I can confirm RB diffs for backports to 1.21 get generated correctly now, and the PR description is updated to include a link to the RB diff. Thanks for reporting on this. There's one issue however -- the

Re: reviewboard update

FWIW, I'd rather we used HTTPS and just fixed whatever issues we had with Ship It, etc. But I'm certainly happiest just to see it working. John =:- On Mon, Nov 17, 2014 at 6:55 PM, Eric Snow eric.s...@canonical.com wrote: On Mon, Nov 17, 2014 at 5:10 AM, Dimiter Naydenov

Re: reviewboard update

Awesome, nice work! On Nov 15, 2014 12:07 AM, Eric Snow eric.s...@canonical.com wrote: FYI, I was able to solve 3 reviewboard-github integration issues today: 1. pull requests for branches other than master now work (e.g. 1.21 backports) 2. no more hitting rate limits (5000 requests/hour

reviewboard update

FYI, I was able to solve 3 reviewboard-github integration issues today: 1. pull requests for branches other than master now work (e.g. 1.21 backports) 2. no more hitting rate limits (5000 requests/hour limit instead of 60) 3. pull request bodies now get updated with a link to the new review

Reviewboard clutter

All, Please close your completed reviews off in Reviewboard. You should only need to do it once for the existing reviews, assuming the integration does its job. Thanks, Andrew -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman

Re: reviewboard - most recent diff by default?

On Mon, Oct 27, 2014 at 9:05 PM, Jesse Meek jesse.m...@canonical.com wrote: Is possible and preferable to show the most recent diff by default? If you mean instead of showing the reviews page by default, ReviewBoard doesn't support that out of the box. Certainly we could customize RB to do so

reviewboard - most recent diff by default?

Is possible and preferable to show the most recent diff by default? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: reviewboard-github integration

On 20/10/14 22:38, Eric Snow wrote: This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. I still have the issue I'm afraid. No reviewer set, no diff. http://reviews.vapour.ws/r/211/ Michael -eric On Mon, Oct 20, 2014 at 7:34 PM,

Re: reviewboard-github integration

On Tue, Oct 21, 2014 at 11:40 AM, Michael Foord michael.fo...@canonical.com wrote: On 20/10/14 22:38, Eric Snow wrote: This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. I still have the issue I'm afraid. No reviewer set, no diff.

Re: reviewboard-github integration

On Tue, Oct 21, 2014 at 3:40 AM, Michael Foord michael.fo...@canonical.com wrote: On 20/10/14 22:38, Eric Snow wrote: This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. I still have the issue I'm afraid. No reviewer set, no diff.

Re: reviewboard-github integration

On Tue, Oct 21, 2014 at 10:12 AM, Eric Snow eric.s...@canonical.com wrote: For now I've hard-coded adding juju-team. If anyone still has trouble with this please let me know. The issue with not finding files in the repo should be fixed now. This means that auto-generated review requests should

Re: reviewboard-github integration

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Eric, Today I tried proposing a PR and the RB issue (#202) was created, but it didn't have Reviewers field set (as described below), it wasn't published (due to the former), but MOST importantly didn't have a diff uploaded. After fiddling around

Re: reviewboard-github integration

Yeah, this is the same issue that Ian brought up. I'm looking into it. Sorry for the pain. -eric On Mon, Oct 20, 2014 at 5:31 PM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Eric, Today I tried proposing a PR and the RB issue

Re: reviewboard-github integration

This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. -eric On Mon, Oct 20, 2014 at 7:34 PM, Eric Snow eric.s...@canonical.com wrote: Yeah, this is the same issue that Ian brought up. I'm looking into it. Sorry for the pain. -eric On

Re: reviewboard-github integration

Hi Eric I just created a pull request for a 1.20 branch and got the same symptoms as seen previously. ie an incomplete review board review without a diff and with a reviewer. On 21/10/14 07:38, Eric Snow wrote: This should be resolved now. I've verified it works for me. If it still impacts

Re: reviewboard-github integration

at least one reviewer was needed. So I had to fill in juju-team and all was good. 1. Can we make it so that the review is published automatically? 2. Can we pre-fill juju-team as the reviewer? On 18/10/14 15:38, Eric Snow wrote: With the switch to Reviewboard we introduced extra steps to our

Re: reviewboard-github integration

On Sat, Oct 18, 2014 at 1:38 PM, Eric Snow eric.s...@canonical.com wrote: With the switch to Reviewboard we introduced extra steps to our workflow (mostly involving rbt). This in turn made things more difficult for new/existing contributors. I've been able to take some time in the last

Re: reviewboard-github integration

And of course if you see any problems please let me know. :) -eric On Sat, Oct 18, 2014 at 7:38 AM, Eric Snow eric.s...@canonical.com wrote: With the switch to Reviewboard we introduced extra steps to our workflow (mostly involving rbt). This in turn made things more difficult for new

reviewboard-github integration

With the switch to Reviewboard we introduced extra steps to our workflow (mostly involving rbt). This in turn made things more difficult for new/existing contributors. I've been able to take some time in the last couple weeks to improve the situation by adding some integration between github

Re: reviewboard-github integration

Also, I did this as a reviewboard extension. All the code is online (BSD license): https://bitbucket.org/ericsnowcurrently/rb_webhooks_extension. I haven't charmed it up, but it should be pretty easy to adapt the charm I wrote for rb_oauth. -eric On Sat, Oct 18, 2014 at 7:38 AM, Eric Snow

Is there a setting in ReviewBoard to let me see *both* the comments and the diffs

Hi Reviewboard is driving me nuts. Either it can't do this, or I have put it in some mode where it does this, but it can only show me the review comments *OR* the diff, but not both. Is there a setting that shows both diffs and the stream of review comments _on_the_same_screen ? Dave -- Juju

Re: Is ReviewBoard a good thing?

On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek jesse.m...@canonical.com wrote: On 20/09/14 02:34, Eric Snow wrote: I was not seriously suggesting we return to lp. Using ReviewBoard reintroduces what we gave up with lp: both the good (tooling that addresses pain points) and the bad (not a well

Re: Is ReviewBoard a good thing?

So, the automation between github and reviewboard seems necessary, so we should do that. It shouldn't be hard at all. Then the steps for submitting code will be: 1.) Submit a PR 2.) Get it reviewed on the automatically-created review. 3.) With a LGTM on the review, mark as $$merge$$ and the bot

Re: The Pros and Cons of ReviewBoard.

Just in case we're counting, another pro: You are able to seperate pushing branches to github and creating a new version of code for review Matty On Fri, Sep 19, 2014 at 4:37 PM, Eric Snow eric.s...@canonical.com wrote: Given that I've in some part driven the switch to ReviewBoard, I want

Re: Is ReviewBoard a good thing?

. It was deemed to have the most mindshare and we sacrificed our prefered platform and process to be part of that mindshare. We are now leaving that 'main stream' process to something that suits the tastes of our team - ReviewBoard. This adds friction for new contributors (friction everyone has

Re: Is ReviewBoard a good thing?

On 19 September 2014 01:32, David Cheney david.che...@canonical.com wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've all learnt

Fwd: Is ReviewBoard a good thing?

On 19 September 2014 01:32, David Cheney david.che...@canonical.com wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've all learnt

Re: Is ReviewBoard a good thing?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.09.2014 03:32, David Cheney wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've

Re: Is ReviewBoard a good thing?

Right now I'm a bit undecided, the usage of ReviewBoard is too fresh. But Jesse made good points and in general Im always happy when we're using less instead of using more tools. I can live with the number of mails, GMail does grouping them fine. And I started to add my comments after a first pass

Re: Is ReviewBoard a good thing?

things rather mainstream as well so as not to increase the entry level requirements fore new contributors? --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 10:14, Frank Mueller wrote: Right now I'm a bit undecided, the usage of ReviewBoard is too fresh. But Jesse made good

Re: Is ReviewBoard a good thing?

There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. On github you need to look in 8 places to see all the stuff up for review, and anything not in juju/juju tends to get lost. This is really important since that can have a big effect on our velocity. I

Re: Is ReviewBoard a good thing?

...@eagleeyet.net Cc: juju-dev@lists.ubuntu.com Subject: Re: Is ReviewBoard a good thing? There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue.  On github you need to look in 8 places to see all the stuff up for review, and anything not in juju/juju tends to get lost

Re: Is ReviewBoard a good thing?

. Chained PR's could probably be done by specifying in the commit message something like: depends on #PR ID Just a thought. Cheers On 19.09.2014 14:32, Nate Finch wrote: There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. On github you need to look in 8

Re: Is ReviewBoard a good thing?

could probably be done by specifying in the commit message something like: depends on #PR ID Just a thought. Cheers On 19.09.2014 14:32, Nate Finch wrote: There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. On github you need to look in 8 places

Re: Is ReviewBoard a good thing?

On Fri, 19 Sep 2014, Nate Finch wrote: There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. Can I ask how kanban doesn't do this job for you? I've heard this said a couple of times but I realized the way I find out what needs to be looked at is to go

Re: Is ReviewBoard a good thing?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.09.2014 16:44, Richard Harding wrote: On Fri, 19 Sep 2014, Nate Finch wrote: There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. Can I ask how kanban doesn't do this job for you? I've heard

Re: Is ReviewBoard a good thing?

On Fri, Sep 19, 2014 at 7:55 AM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: +1, In addition you can always check https://github.com/juju/juju/pulls to see what's in the queue. For sub-repositories it's the same, like https://github.com/juju/names/pulls. While I agree it's not all

Re: Is ReviewBoard a good thing?

We will all be seeing each other in 2 weeks we can discuss it then On Friday, September 19, 2014, Eric Snow eric.s...@canonical.com wrote: On Fri, Sep 19, 2014 at 7:55 AM, Matthew Williams matthew.willi...@canonical.com javascript:; wrote: I do think it's too early to tell though. Why not

Re: Is ReviewBoard a good thing?

On Fri, Sep 19, 2014 at 8:34 AM, Eric Snow eric.s...@canonical.com wrote: I agree that reviewboard as we currently have it now adds extra work to our workflow. Not only does this impact the juju team, but it does add a stumbling block to more community involvement. However, my firm belief

Re: Is ReviewBoard a good thing?

On Fri, Sep 19, 2014 at 6:11 AM, Gabriel Samfira gsamf...@cloudbasesolutions.com wrote: Just a suggestion: A git plugin similar to what Gerrit has would simplify things. For example, Gerrit has a nice little plugin called Review. Simply doing: git review In your current branch would push

Re: Is ReviewBoard a good thing?

On Thu, Sep 18, 2014 at 6:32 PM, David Cheney david.che...@canonical.com wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. It will be worth being extra clear on ReviewBoard's

The Pros and Cons of ReviewBoard.

Given that I've in some part driven the switch to ReviewBoard, I want to make sure we are all on the same page and any decision on its future can be made objectively. This is an outgrowth of the current discussion on whether or not we should ditch reviewboard. Let's look at the pros and cons

Re: The Pros and Cons of ReviewBoard.

On Fri, Sep 19, 2014 at 9:37 AM, Eric Snow eric.s...@canonical.com wrote: Given that I've in some part driven the switch to ReviewBoard, I want to make sure we are all on the same page and any decision on its future can be made objectively. This is an outgrowth of the current discussion

Re: The Pros and Cons of ReviewBoard.

I am more than willing to help out wity those modifications Sent from Samsung Mobile Original message From: Eric Snow eric.s...@canonical.com Date: 19/09/2014 5:41 PM (GMT+01:00) To: juju-dev@lists.ubuntu.com Subject: Re: The Pros and Cons of ReviewBoard. On Fri, Sep

Re: The Pros and Cons of ReviewBoard.

At the risk of opening a can of worms: Reviewboard doesn't have to be a barrier to contributing. We could allow new contributors/ drive by fixes to use github. Matty On 19 Sep 2014 17:05, Eric Snow eric.s...@canonical.com wrote: On Fri, Sep 19, 2014 at 9:48 AM, Jonathan Aquilina jaquil

Re: The Pros and Cons of ReviewBoard.

If we automate the creation of reviewboard reviews whenever a pull request is made, it would make it trivial even for outsiders. On Sep 19, 2014 5:01 PM, Matthew Williams matthew.willi...@canonical.com wrote: At the risk of opening a can of worms: Reviewboard doesn't have to be a barrier

Re: Is ReviewBoard a good thing?

On Sat, Sep 20, 2014 at 1:02 AM, Eric Snow eric.s...@canonical.com wrote: On Thu, Sep 18, 2014 at 6:32 PM, David Cheney david.che...@canonical.com wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way

Re: The Pros and Cons of ReviewBoard.

Thats what im suggesting be it coding somethign from scratch or adapting RB to make it much easier to work with. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 23:01, Matthew Williams wrote: At the risk of opening a can of worms: Reviewboard doesn't have

Re: The Pros and Cons of ReviewBoard.

I also suggested in another part of the thread sending an email when a new request is submitted to all those invovled with the reviewing. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 23:14, Nate Finch wrote: If we automate the creation of reviewboard reviews whenever

Re: Doing chained diffs w/ Reviewboard

On 18 September 2014 10:49, John Meinel j...@arbash-meinel.com wrote: Has anyone succeeded in getting this to work? The steps I tried to do were: git co master git pull upstream master git co base-branch git diff master... base.diff git co dependent-branch git diff master...

Re: Doing chained diffs w/ Reviewboard

I've got it working. Using rbt it was pretty trivial. I'm not 100% sure of my steps - but from memory and some prompting from `history` the process was more or less: 1) rebase my branch against the latest version of the parent. Then: 2) rbt post -parent remotes/mattyw/my-parent-branch It

Re: Doing chained diffs w/ Reviewboard

So I did get rbt post to work with rbt post -r 54 --parent=REVID, I had to be careful because my actual parent branch *didn't* merge the current tip of master but the one I was proposing had. So instead I ended up rebasing both commits, and then specifying the PARENT as the specific rebased commit

Re: Doing chained diffs w/ Reviewboard

, as Reviewboard seems to just think in terms of diffs. (rbt -u just guesses what review is associated to your branch by looking at the summary messages, there is no direct link to a branch AFAICT) John =:- On Thu, Sep 18, 2014 at 2:45 PM, Ian Booth ian.bo...@canonical.com wrote: On 18/09/14 20

Re: Doing chained diffs w/ Reviewboard

+1 to that On Thu, Sep 18, 2014 at 7:53 PM, Adam Collard adam.coll...@canonical.com wrote: On 18 September 2014 10:49, John Meinel j...@arbash-meinel.com wrote: Has anyone succeeded in getting this to work? The steps I tried to do were: git co master git pull upstream master git co

Re: Doing chained diffs w/ Reviewboard

Also, be watchful for the other reviewboard footgun, paged diffs. Reviewboard pages large reviews, so if you're used to thinking 'phew, i've gotten to the end of the page, i'm done, check again, there maybe a surprise waiting for you at the bottom of the page. On Thu, Sep 18, 2014 at 9:03 PM

Is ReviewBoard a good thing?

of that mindshare. We are now leaving that 'main stream' process to something that suits the tastes of our team - ReviewBoard. This adds friction for new contributors (friction everyone has experienced this week). If we value our preferred methods of reviewing over keeping to a well known process

Re: Is ReviewBoard a good thing?

There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've all learnt to live with the first issue On the second, github now does nice side by side

Re: ReviewBoard is now the official review tool for juju

On 15 September 2014 21:39, Ian Booth ian.bo...@canonical.com wrote: On 16/09/14 00:50, Eric Snow wrote: On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow eric.s...@canonical.com wrote: Yeah, those steps are a lot, though keep in mind that effectively it's only 2 steps more than before if you use the

Re: ReviewBoard is now the official review tool for juju

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 10:44, roger peppe wrote: As far as I can make out, as long as you want to propose your branch with only a single commit added to the log, this makes it easy to use a merge-based flow and amounts to the same thing in the end. I

Re: ReviewBoard is now the official review tool for juju

If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5 step process into one merge and one push. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 09:44, roger peppe wrote: On 15 September

Re: ReviewBoard is now the official review tool for juju

On 16 September 2014 09:22, Jonathan Aquilina jaquil...@eagleeyet.net wrote: If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5 step process into one merge and one push. I don't see that command. Are you

Re: ReviewBoard is now the official review tool for juju

I dont think you have to rebase though. I think you can squash multiple commits together. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 11:27, roger peppe wrote: On 16 September 2014 09:22, Jonathan Aquilina jaquil...@eagleeyet.net wrote: If i am not mistaken if you

Re: ReviewBoard is now the official review tool for juju

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 12:32, Jonathan Aquilina wrote: I dont think you have to rebase though. I think you can squash multiple commits together. You're probably thinking about git commit --amend -m msg, which folds the current changeset into the one

Re: ReviewBoard is now the official review tool for juju

That is it indeed :) --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 11:58, Dimiter Naydenov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 12:32, Jonathan Aquilina wrote: I dont think you have to rebase though. I think you can squash multiple

Re: ReviewBoard is now the official review tool for juju

On Tue, Sep 16, 2014 at 7:27 PM, roger peppe roger.pe...@canonical.com wrote: On 16 September 2014 09:22, Jonathan Aquilina jaquil...@eagleeyet.net wrote: If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5

Re: ReviewBoard is now the official review tool for juju

On 16 September 2014 13:45, David Cheney david.che...@canonical.com wrote: On Tue, Sep 16, 2014 at 7:27 PM, roger peppe roger.pe...@canonical.com wrote: On 16 September 2014 09:22, Jonathan Aquilina jaquil...@eagleeyet.net wrote: If i am not mistaken if you have multiple commits in a branch

Re: ReviewBoard is now the official review tool for juju

run in to one issue so far. When I tried to get my first review in to Reviewboard today it took me a long time to figure out how to get it to generate the correct diff. After much gnashing of teeth I figured out that rbt post generates a diff by comparing origin/master against the current

Re: ReviewBoard is now the official review tool for juju

On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow eric.s...@canonical.com wrote: Yeah, those steps are a lot, though keep in mind that effectively it's only 2 steps more than before if you use the -p flag to rbt post and were already keeping your local master up to date. Just to be clear, here are

Re: ReviewBoard is now the official review tool for juju

Really, rbt pull -p is the only new step. All the rest of that is stuff you should already be doing as a normal part of writing code and making pull requests. I guess adding the link on the PR to the review is also a new step. If you really want to count that as a step. On Mon, Sep 15, 2014 at

Re: ReviewBoard is now the official review tool for juju

Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat concerning to me that our reviews are now disconnected from what will actually be landed into trunk. In Github, you were reviewing the actual diff which would be landed. In reviewboard, we're now

Re: ReviewBoard is now the official review tool for juju

On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat concerning to me that our reviews are now disconnected from what will actually be landed into trunk

Re: ReviewBoard is now the official review tool for juju

... There is the possibility of pushing info from ReviewBoard back to github (e.g. ship-it - LGTM comment), but I don't think it buys us enough to make it worth it (it's notably trickier). -eric I would think it would be just as easy to change the bot to merge based on comments

Re: ReviewBoard is now the official review tool for juju

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Eric, On 15.09.2014 21:18, Eric Snow wrote: On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat

Re: ReviewBoard is now the official review tool for juju

, Dimiter Naydenov wrote: Hi Eric, On 15.09.2014 21:18, Eric Snow wrote: On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat concerning to me that our

Re: ReviewBoard is now the official review tool for juju

On Mon, Sep 15, 2014 at 12:54 PM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: - From my meager experience with writing git plugins (any executable in $PATH with git- prefix), what are you describing can be easily achieved. If you write a git plugin, named e.g. git-rbpropose, using

  1   2   >