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-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 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 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 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: Juju 2.0 is here!

2016-10-14 Thread Katherine Cox-Buday 
Nicholas Skaggs  writes:

> Juju 2.0 is here!

YES! Time to upgrade my production 1.25 installation :D

Congratulations, everyone.

-- 
Katherine

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

Re: Juju 2.0 is here!

2016-10-14 Thread Antonio Rosales 
Congrats on the 2.0 GA release!

-Antonio

On Thursday, October 13, 2016, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Juju 2.0 is here! This release has been a year in the making. We’d like to
> thank everyone for their feedback, testing, and adoption of juju 2.0
> throughout its development process! Juju brings refinements in ease of use,
> while adding support for new clouds and features.
>
> ## New to juju 2?
>
> https://jujucharms.com/docs/2.0/getting-started
>
> ## Need to install it?
>
> If you are running Ubuntu, you can get it from the juju stable ppa:
>
> sudo add-apt-repository ppa:juju/stable
> sudo apt update; sudo apt install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0.0
>
> ## Want to upgrade to GA?
>
> Those of you running an RC version of juju 2 can upgrade to this release
> by running:
>
> juju upgrade-juju
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> j...@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>


-- 
-Thanks
Antonio
-- 
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 02:16, Menno Smits  wrote:

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

It's funny how these things pan out: I went in the other way...

+1
-- 
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 Nate Finch 
+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
>
-- 
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 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
> > mailto: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
> > > 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 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
> mailto: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
> > 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 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
> > > mailto: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
> > > > 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 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 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 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: Juju 2.0 is here!

2016-10-14 Thread Andrew Wilkins 
On Fri, 14 Oct 2016, 12:34 p.m. Nicholas Skaggs, <
nicholas.ska...@canonical.com> wrote:

Juju 2.0 is here! This release has been a year in the making. We’d like
to thank everyone for their feedback, testing, and adoption of juju 2.0
throughout its development process! Juju brings refinements in ease of
use, while adding support for new clouds and features.


What an epic release! I for one am proud of what we've created together.
Great work everyone.

## New to juju 2?

https://jujucharms.com/docs/2.0/getting-started

## Need to install it?

If you are running Ubuntu, you can get it from the juju stable ppa:

 sudo add-apt-repository ppa:juju/stable
 sudo apt update; sudo apt install juju-2.0

Or install it from the snap store

 snap install juju --beta --devmode

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0.0

## Want to upgrade to GA?

Those of you running an RC version of juju 2 can upgrade to this release
by running:

juju upgrade-juju

## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
j...@lists.ubuntu.com and join us on #juju on freenode. We would love to
hear
your feedback and usage of juju.


--
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