Re: Github Reviews vs Reviewboard

2016-10-24 Thread Menno Smits
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 notes, e.g.
> https://github.com/google/git-appraise
>
> With git's ability to rewrite history, I bet this is doable...
>

​+1
​This is a great idea.
​ We could also import the old reviews from ​
codereview.appspot.com
​.​

For those who don't know what git notes are, they're a way of adding extra
information to commits without modifying the commit itself. Notes can be
viewed and manipulated using the "git notes" subcommand. "git show" will
also show any notes for a commit.

Github used to display notes but no longer does for some reason.

- Menno
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-24 Thread Katherine Cox-Buday
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 is doable...

-- 
Katherine

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-24 Thread Menno Smits
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 unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-24 Thread Horacio Duran
Shouldn't we leave it for historic purposes?

On Monday, 24 October 2016, Menno Smits  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 Reviewboard
> instance.
>
> On 15 October 2016 at 06:57, Casey Marshall  > wrote:
>
>> +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 kind of rough on the uninitiated. Maybe if a newer
>> version of RB was sufficiently improved and it was charmed up well, its
>> operation would be more manageable, and it'd be OK?
>>
>> -Casey
>>
>> On Fri, Oct 14, 2016 at 12:34 PM, Andrew McDermott <
>> andrew.mcderm...@canonical.com
>> > wrote:
>>
>>>
>>> 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 
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> 
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> 
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-24 Thread Menno Smits
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 
wrote:

> +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 kind of rough on the uninitiated. Maybe if a newer
> version of RB was sufficiently improved and it was charmed up well, its
> operation would be more manageable, and it'd be OK?
>
> -Casey
>
> On Fri, Oct 14, 2016 at 12:34 PM, Andrew McDermott <
> andrew.mcderm...@canonical.com> wrote:
>
>>
>> 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 
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Casey Marshall
+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 kind of rough on the uninitiated. Maybe if a newer
version of RB was sufficiently improved and it was charmed up well, its
operation would be more manageable, and it'd be OK?

-Casey

On Fri, Oct 14, 2016 at 12:34 PM, Andrew McDermott <
andrew.mcderm...@canonical.com> wrote:

>
> 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 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Andrew McDermott
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 
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Reed O'Brien
+1

I expect there will be updates and improvements to GH reviews over time.
e.g. the 'show notes' checkbox to hide the notes when looking at the
changes. I don't recall seeing that last week. I think gitlab's funding and
cadence if putting pressure on GH to improve their UI and feature set.

They are just tools. Neither is perfect, but I find GH to be less
problematic and less bumpy in my general work flow. I've lost work in RB
more than a few times, which is not an experience I've had with GH. I find
the diffs in RB inscrutable at times and have had go to look a them in GH.

I'd be happy to try gerrit. I haven't used it, but everyone I've spoken
with who has reported a positive experience. I'd also be happy to try
gitlab, but that is another, enormous, can of worms.



On Thu, Oct 13, 2016 at 3:59 PM, Ian Booth  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 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 Reviewboard
> >- 0 means you don't mind.
> >
> > If you don't mind which review system we use there's no need to reply
> > unless you want to voice some opinions.
> >
> > The voting period starts *now* and ends my* EOD next Friday (October
> 21)*.
> >
> > As a refresher, here are the concerns raised for each option.
> >
> > *Github Reviews*
> >
> >- Comments disrupt the flow of the code and can't be minimised,
> >hindering readability.
> >- Comments can't be marked as done making it hard to see what's still
> to
> >be taken care of.
> >- There's no way to distinguish between a problem and a comment.
> >- There's no summary of issues raised. You need to scroll through the
> >often busy discussion page.
> >- There's no indication of which PRs have been reviewed from the pull
> >request index page nor is it possible to see which PRs have been
> approved
> >or otherwise.
> >- It's hard to see when a review has been updated.
> >
> > *Reviewboard*
> >
> >- Another piece of infrastructure for us to maintain
> >- Higher barrier to entry for newcomers and outside contributors
> >- Occasionally misses Github pull requests (likely a problem with our
> >integration so is fixable)
> >- Poor handling of deleted and renamed files
> >- Falls over with very large diffs
> >- 1990's looks :)
> >- May make future integration of tools which work with Github into our
> >process more difficult (e.g. static analysis or automated review
> tools)
> >
> > There has been talk of evaluating other review tools such as Gerrit and
> > that may still happen. For now, let's decide between the two options we
> > have recent experience with.
> >
> > - Menno
> >
> >
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>



-- 
Reed O'Brien
✉ reed.obr...@canonical.com
✆ 415-562-6797
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Mick Gregg
+1 Perhaps I'm too new to understand what rb truly offers, but one less
tool has been noticeably better for me, and I haven't felt any pain in
gh.

I would probably chose gerrit over either, but that's not the question
today.

On Fri, Oct 14, 2016 at 12:10:56PM -0300, Horacio Duran wrote:
> +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
> > >
> > > Keeping the PR and reviews together really makes it easier for me to
> > > keep track of what's going on with a PR.  It's also really nice not
> > > having to context switch out of github for 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 haven't really cared about the drawbacks of github.
> > >
> > > One point - you *can* minimize comments in the files view - there's a
> > > checkbox per file that will hide the comments in that file.
> > >
> > > On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > > > wrote:
> > >
> > > On 14 October 2016 at 12:45, Adam Collard
> > > >
> > 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
> > > > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> > > development and
> > > > brings a chunk of new UI improvements.
> > > >
> > > > Release notes for 2.5
> > > >
> > > > 3.0 demo site
> > >
> > > I'm still not convinced.
> > >
> > > Even 3.0 still deletes draft comments without so much as a
> > by-your-leave
> > > when you double-click somewhere else in the text. And because it
> > > doesn't use
> > > real text entry boxes, the Lazarus plugin, my usual saviour in such
> > > cases,
> > > doesn't work. I've lost far too much time to this in the past.
> > >
> > > Replying to a comment still involves a page reload and associated
> > > lost context.
> > >
> > > I can't see anything in the 2.5 release notes about fixing behaviour
> > > on file
> > > move/rename, though I may well have missed it.
> > >
> > > And not being able to deal with really large PRs is a definite issue
> > > too (not
> > > that github is better there).
> > >
> > >   cheers,
> > > rog.
> > >
> > > --
> > > Juju-dev mailing list
> > > Juju-dev@lists.ubuntu.com 
> > > Modify settings or unsubscribe at:
> > > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > >
> > >
> > >
> >
> >
> > --
> > Dimiter Naydenov 
> > Juju Core Sapphire team 
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/
> > mailman/listinfo/juju-dev
> >
> >

> -- 
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Dimiter Naydenov
+1, Nate said what I was thinking :)

On 10/14/2016 05:34 PM, Nate Finch wrote:
> +1
> 
> Keeping the PR and reviews together really makes it easier for me to
> keep track of what's going on with a PR.  It's also really nice not
> having to context switch out of github for 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 haven't really cared about the drawbacks of github.
> 
> One point - you *can* minimize comments in the files view - there's a
> checkbox per file that will hide the comments in that file.
> 
> On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > wrote:
> 
> On 14 October 2016 at 12:45, Adam Collard
> > 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
> > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> development and
> > brings a chunk of new UI improvements.
> >
> > Release notes for 2.5
> >
> > 3.0 demo site
> 
> I'm still not convinced.
> 
> Even 3.0 still deletes draft comments without so much as a by-your-leave
> when you double-click somewhere else in the text. And because it
> doesn't use
> real text entry boxes, the Lazarus plugin, my usual saviour in such
> cases,
> doesn't work. I've lost far too much time to this in the past.
> 
> Replying to a comment still involves a page reload and associated
> lost context.
> 
> I can't see anything in the 2.5 release notes about fixing behaviour
> on file
> move/rename, though I may well have missed it.
> 
> And not being able to deal with really large PRs is a definite issue
> too (not
> that github is better there).
> 
>   cheers,
> rog.
> 
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 


-- 
Dimiter Naydenov 
Juju Core Sapphire team 



signature.asc
Description: OpenPGP digital signature
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Horacio Duran
+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
> >
> > Keeping the PR and reviews together really makes it easier for me to
> > keep track of what's going on with a PR.  It's also really nice not
> > having to context switch out of github for 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 haven't really cared about the drawbacks of github.
> >
> > One point - you *can* minimize comments in the files view - there's a
> > checkbox per file that will hide the comments in that file.
> >
> > On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > > wrote:
> >
> > On 14 October 2016 at 12:45, Adam Collard
> > >
> 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
> > > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> > development and
> > > brings a chunk of new UI improvements.
> > >
> > > Release notes for 2.5
> > >
> > > 3.0 demo site
> >
> > I'm still not convinced.
> >
> > Even 3.0 still deletes draft comments without so much as a
> by-your-leave
> > when you double-click somewhere else in the text. And because it
> > doesn't use
> > real text entry boxes, the Lazarus plugin, my usual saviour in such
> > cases,
> > doesn't work. I've lost far too much time to this in the past.
> >
> > Replying to a comment still involves a page reload and associated
> > lost context.
> >
> > I can't see anything in the 2.5 release notes about fixing behaviour
> > on file
> > move/rename, though I may well have missed it.
> >
> > And not being able to deal with really large PRs is a definite issue
> > too (not
> > that github is better there).
> >
> >   cheers,
> > rog.
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com 
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
>
>
> --
> Dimiter Naydenov 
> Juju Core Sapphire team 
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread roger peppe
[from canonical email address this time]

On 14 October 2016 at 12:45, Adam Collard  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
> revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
> brings a chunk of new UI improvements.
>
> Release notes for 2.5
>
> 3.0 demo site

I'm still not convinced.

Even 3.0 still deletes draft comments without so much as a by-your-leave
when you double-click somewhere else in the text. And because it doesn't use
real text entry boxes, the Lazarus plugin, my usual saviour in such cases,
doesn't work. I've lost far too much time to this in the past.

Replying to a comment still involves a page reload and associated lost context.

I can't see anything in the 2.5 release notes about fixing behaviour on file
move/rename, though I may well have missed it.

And not being able to deal with really large PRs is a definite issue too (not
that github is better there).

  cheers,
rog.

On 14 October 2016 at 12:45, Adam Collard  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
> revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
> brings a chunk of new UI improvements.
>
> Release notes for 2.5
>
> 3.0 demo site
>
> On Fri, 14 Oct 2016 at 12:34 Michael Foord 
> wrote:
>>
>> 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 followed by any further
>> thoughts.
>>
>> +1 means you prefer Github Reviews
>> -1 means you prefer Reviewboard
>> 0 means you don't mind.
>>
>> If you don't mind which review system we use there's no need to reply
>> unless you want to voice some opinions.
>>
>> The voting period starts now and ends my EOD next Friday (October 21).
>>
>> As a refresher, here are the concerns raised for each option.
>>
>> Github Reviews
>>
>> Comments disrupt the flow of the code and can't be minimised, hindering
>> readability.
>> Comments can't be marked as done making it hard to see what's still to be
>> taken care of.
>> There's no way to distinguish between a problem and a comment.
>> There's no summary of issues raised. You need to scroll through the often
>> busy discussion page.
>> There's no indication of which PRs have been reviewed from the pull
>> request index page nor is it possible to see which PRs have been approved or
>> otherwise.
>> It's hard to see when a review has been updated.
>>
>> Reviewboard
>>
>> Another piece of infrastructure for us to maintain
>> Higher barrier to entry for newcomers and outside contributors
>> Occasionally misses Github pull requests (likely a problem with our
>> integration so is fixable)
>> Poor handling of deleted and renamed files
>> Falls over with very large diffs
>> 1990's looks :)
>> May make future integration of tools which work with Github into our
>> process more difficult (e.g. static analysis or automated review tools)
>>
>> There has been talk of evaluating other review tools such as Gerrit and
>> that may still happen. For now, let's decide between the two options we have
>> recent experience with.
>>
>> - Menno
>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread roger peppe
On 14 October 2016 at 12:45, Adam Collard  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
> revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
> brings a chunk of new UI improvements.
>
> Release notes for 2.5
>
> 3.0 demo site

I'm still not convinced.

Even 3.0 still deletes draft comments without so much as a by-your-leave
when you double-click somewhere else in the text. And because it doesn't use
real text entry boxes, the Lazarus plugin, my usual saviour in such cases,
doesn't work. I've lost far too much time to this in the past.

Replying to a comment still involves a page reload and associated lost context.

I can't see anything in the 2.5 release notes about fixing behaviour on file
move/rename, though I may well have missed it.

And not being able to deal with really large PRs is a definite issue too (not
that github is better there).

  cheers,
rog.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Adam Collard
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.

Release notes for 2.5


3.0 demo site 

On Fri, 14 Oct 2016 at 12:34 Michael Foord 
wrote:

> 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 followed by any further
> thoughts.
>
>- +1 means you prefer Github Reviews
>- -1 means you prefer Reviewboard
>- 0 means you don't mind.
>
> If you don't mind which review system we use there's no need to reply
> unless you want to voice some opinions.
>
> The voting period starts *now* and ends my* EOD next Friday (October 21)*.
>
> As a refresher, here are the concerns raised for each option.
>
> *Github Reviews*
>
>- Comments disrupt the flow of the code and can't be minimised,
>hindering readability.
>- Comments can't be marked as done making it hard to see what's still
>to be taken care of.
>- There's no way to distinguish between a problem and a comment.
>- There's no summary of issues raised. You need to scroll through the
>often busy discussion page.
>- There's no indication of which PRs have been reviewed from the pull
>request index page nor is it possible to see which PRs have been approved
>or otherwise.
>- It's hard to see when a review has been updated.
>
> *Reviewboard*
>
>- Another piece of infrastructure for us to maintain
>- Higher barrier to entry for newcomers and outside contributors
>- Occasionally misses Github pull requests (likely a problem with our
>integration so is fixable)
>- Poor handling of deleted and renamed files
>- Falls over with very large diffs
>- 1990's looks :)
>- May make future integration of tools which work with Github into our
>process more difficult (e.g. static analysis or automated review tools)
>
> There has been talk of evaluating other review tools such as Gerrit and
> that may still happen. For now, let's decide between the two options we
> have recent experience with.
>
> - Menno
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread Michael Foord

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 followed by any 
further thoughts.


  * +1 means you prefer Github Reviews
  * -1 means you prefer Reviewboard
  * 0 means you don't mind.

If you don't mind which review system we use there's no need to reply 
unless you want to voice some opinions.


The voting period starts *now* and ends my*EOD next Friday (October 21)*.

As a refresher, here are the concerns raised for each option.

*Github Reviews*

  * Comments disrupt the flow of the code and can't be minimised,
hindering readability.
  * Comments can't be marked as done making it hard to see what's
still to be taken care of.
  * There's no way to distinguish between a problem and a comment.
  * There's no summary of issues raised. You need to scroll through
the often busy discussion page.
  * There's no indication of which PRs have been reviewed from the
pull request index page nor is it possible to see which PRs have
been approved or otherwise.
  * It's hard to see when a review has been updated.

*Reviewboard*

  * Another piece of infrastructure for us to maintain
  * Higher barrier to entry for newcomers and outside contributors
  * Occasionally misses Github pull requests (likely a problem with
our integration so is fixable)
  * Poor handling of deleted and renamed files
  * Falls over with very large diffs
  * 1990's looks :)
  * May make future integration of tools which work with Github into
our process more difficult (e.g. static analysis or automated
review tools)

There has been talk of evaluating other review tools such as Gerrit 
and that may still happen. For now, let's decide between the two 
options we have recent experience with.


- Menno




-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread roger peppe
+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 are divorced from the
original PR.

Of course, the last point is true of any external tool, but I find reviewboard
constantly frustrating. If the decision was between github and gerrit, I'd
choose gerrit - having used it as part of the Go project, I find it's
much better
in all respects than reviewboard.

  rog.


On 13 October 2016 at 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 followed by any further
> thoughts.
>
> +1 means you prefer Github Reviews
> -1 means you prefer Reviewboard
> 0 means you don't mind.
>
> If you don't mind which review system we use there's no need to reply unless
> you want to voice some opinions.
>
> The voting period starts now and ends my EOD next Friday (October 21).
>
> As a refresher, here are the concerns raised for each option.
>
> Github Reviews
>
> Comments disrupt the flow of the code and can't be minimised, hindering
> readability.
> Comments can't be marked as done making it hard to see what's still to be
> taken care of.
> There's no way to distinguish between a problem and a comment.
> There's no summary of issues raised. You need to scroll through the often
> busy discussion page.
> There's no indication of which PRs have been reviewed from the pull request
> index page nor is it possible to see which PRs have been approved or
> otherwise.
> It's hard to see when a review has been updated.
>
> Reviewboard
>
> Another piece of infrastructure for us to maintain
> Higher barrier to entry for newcomers and outside contributors
> Occasionally misses Github pull requests (likely a problem with our
> integration so is fixable)
> Poor handling of deleted and renamed files
> Falls over with very large diffs
> 1990's looks :)
> May make future integration of tools which work with Github into our process
> more difficult (e.g. static analysis or automated review tools)
>
> There has been talk of evaluating other review tools such as Gerrit and that
> may still happen. For now, let's decide between the two options we have
> recent experience with.
>
> - Menno
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-14 Thread James Tunnicliffe
-1

On 14 October 2016 at 02:47, Tim Penhey  wrote:
> -1, like Menno I was initially quite hopeful for the github reviews.
>
> My main concerns are around easily having a list to pull from, and being
> able to see status, comments on a single dashboard.
>
> 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 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 Reviewboard
>>   * 0 means you don't mind.
>>
>> If you don't mind which review system we use there's no need to reply
>> unless you want to voice some opinions.
>>
>> The voting period starts *now* and ends my*EOD next Friday (October 21)*.
>>
>> As a refresher, here are the concerns raised for each option.
>>
>> *Github Reviews*
>>
>>   * Comments disrupt the flow of the code and can't be minimised,
>> hindering readability.
>>   * Comments can't be marked as done making it hard to see what's still
>> to be taken care of.
>>   * There's no way to distinguish between a problem and a comment.
>>   * There's no summary of issues raised. You need to scroll through the
>> often busy discussion page.
>>   * There's no indication of which PRs have been reviewed from the pull
>> request index page nor is it possible to see which PRs have been
>> approved or otherwise.
>>   * It's hard to see when a review has been updated.
>>
>> *Reviewboard*
>>
>>   * Another piece of infrastructure for us to maintain
>>   * Higher barrier to entry for newcomers and outside contributors
>>   * Occasionally misses Github pull requests (likely a problem with our
>> integration so is fixable)
>>   * Poor handling of deleted and renamed files
>>   * Falls over with very large diffs
>>   * 1990's looks :)
>>   * May make future integration of tools which work with Github into our
>> process more difficult (e.g. static analysis or automated review
>> tools)
>>
>> There has been talk of evaluating other review tools such as Gerrit and
>> that may still happen. For now, let's decide between the two options we
>> have recent experience with.
>>
>> - Menno
>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-13 Thread Tim Penhey

-1, like Menno I was initially quite hopeful for the github reviews.

My main concerns are around easily having a list to pull from, and being 
able to see status, comments on a single dashboard.


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 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 Reviewboard
  * 0 means you don't mind.

If you don't mind which review system we use there's no need to reply
unless you want to voice some opinions.

The voting period starts *now* and ends my*EOD next Friday (October 21)*.

As a refresher, here are the concerns raised for each option.

*Github Reviews*

  * Comments disrupt the flow of the code and can't be minimised,
hindering readability.
  * Comments can't be marked as done making it hard to see what's still
to be taken care of.
  * There's no way to distinguish between a problem and a comment.
  * There's no summary of issues raised. You need to scroll through the
often busy discussion page.
  * There's no indication of which PRs have been reviewed from the pull
request index page nor is it possible to see which PRs have been
approved or otherwise.
  * It's hard to see when a review has been updated.

*Reviewboard*

  * Another piece of infrastructure for us to maintain
  * Higher barrier to entry for newcomers and outside contributors
  * Occasionally misses Github pull requests (likely a problem with our
integration so is fixable)
  * Poor handling of deleted and renamed files
  * Falls over with very large diffs
  * 1990's looks :)
  * May make future integration of tools which work with Github into our
process more difficult (e.g. static analysis or automated review tools)

There has been talk of evaluating other review tools such as Gerrit and
that may still happen. For now, let's decide between the two options we
have recent experience with.

- Menno




--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-13 Thread Menno Smits
-1

I was really excited by Github Reviews initially but after using it for a
while I've switched my position.

On 14 October 2016 at 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 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 Reviewboard
>- 0 means you don't mind.
>
> If you don't mind which review system we use there's no need to reply
> unless you want to voice some opinions.
>
> The voting period starts *now* and ends my* EOD next Friday (October 21)*.
>
> As a refresher, here are the concerns raised for each option.
>
> *Github Reviews*
>
>- Comments disrupt the flow of the code and can't be minimised,
>hindering readability.
>- Comments can't be marked as done making it hard to see what's still
>to be taken care of.
>- There's no way to distinguish between a problem and a comment.
>- There's no summary of issues raised. You need to scroll through the
>often busy discussion page.
>- There's no indication of which PRs have been reviewed from the pull
>request index page nor is it possible to see which PRs have been approved
>or otherwise.
>- It's hard to see when a review has been updated.
>
> *Reviewboard*
>
>- Another piece of infrastructure for us to maintain
>- Higher barrier to entry for newcomers and outside contributors
>- Occasionally misses Github pull requests (likely a problem with our
>integration so is fixable)
>- Poor handling of deleted and renamed files
>- Falls over with very large diffs
>- 1990's looks :)
>- May make future integration of tools which work with Github into our
>process more difficult (e.g. static analysis or automated review tools)
>
> There has been talk of evaluating other review tools such as Gerrit and
> that may still happen. For now, let's decide between the two options we
> have recent experience with.
>
> - Menno
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Github Reviews vs Reviewboard

2016-10-13 Thread Ian Booth
-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 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 Reviewboard
>- 0 means you don't mind.
> 
> If you don't mind which review system we use there's no need to reply
> unless you want to voice some opinions.
> 
> The voting period starts *now* and ends my* EOD next Friday (October 21)*.
> 
> As a refresher, here are the concerns raised for each option.
> 
> *Github Reviews*
> 
>- Comments disrupt the flow of the code and can't be minimised,
>hindering readability.
>- Comments can't be marked as done making it hard to see what's still to
>be taken care of.
>- There's no way to distinguish between a problem and a comment.
>- There's no summary of issues raised. You need to scroll through the
>often busy discussion page.
>- There's no indication of which PRs have been reviewed from the pull
>request index page nor is it possible to see which PRs have been approved
>or otherwise.
>- It's hard to see when a review has been updated.
> 
> *Reviewboard*
> 
>- Another piece of infrastructure for us to maintain
>- Higher barrier to entry for newcomers and outside contributors
>- Occasionally misses Github pull requests (likely a problem with our
>integration so is fixable)
>- Poor handling of deleted and renamed files
>- Falls over with very large diffs
>- 1990's looks :)
>- May make future integration of tools which work with Github into our
>process more difficult (e.g. static analysis or automated review tools)
> 
> There has been talk of evaluating other review tools such as Gerrit and
> that may still happen. For now, let's decide between the two options we
> have recent experience with.
> 
> - Menno
> 
> 
> 

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev