Re: Is ReviewBoard a good thing?

2014-09-19 Thread roger peppe
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 to live with
 the first issue

 On the second, github now does nice side by side diffs.

 On the third, it appears reviewboard leaves you solidly to your own
 devices to implement chained proposals.

 I'm with Jesse, I vote to stop using reviewboard, I don't think it's
 paying it's way.

The main thing I was hoping to get from reviewboard that's
a constant pain to me in github was the ability to look
at new changes in the context of old comments, to see
where and how those comments have been addressed.

So, assuming reviewboard did address that issue, I'm a
bit sad but I think Jesse makes a very
good point about keeping things mainstream.

I guess there's the potential for some third party tool
to address my issue above.

So I agree that it might be better to cut losses here and embrace
github, even if it is awkward in some ways.

  cheers,
rog.

 On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com wrote:
 We moved to GitHub in the hope of lowering the bar to contributors outside
 the team. GitHub is *the* platform and process for open source software.
 This was the logic behind the move. 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 experienced this week). If we value our preferred
 methods of reviewing over keeping to a well known process for outside
 contributors, the best process was launchpad + rietveld. Shouldn't we simply
 return to that.

 Considering we have been successfully using GitHub for several months now,
 using reviewboard is not a necessity. Obviously, I will go with whatever the
 team decides, but I'm concerned that we have moved to reviewboard without
 considering that it undermines (as far as I can see) our primary reason for
 using GitHub.

 Jess

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


Fwd: Is ReviewBoard a good thing?

2014-09-19 Thread roger peppe
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 to live with
 the first issue

 On the second, github now does nice side by side diffs.

 On the third, it appears reviewboard leaves you solidly to your own
 devices to implement chained proposals.

 I'm with Jesse, I vote to stop using reviewboard, I don't think it's
 paying it's way.

The main thing I was hoping to get from reviewboard that's
a constant pain to me in github was the ability to look
at new changes in the context of old comments, to see
where and how those comments have been addressed.

So, assuming reviewboard did address that issue, I'm a
bit sad but I think Jesse makes a very
good point about keeping things mainstream.

I guess there's the potential for some third party tool
to address my issue above.

So I agree that it might be better to cut losses here and embrace
github, even if it is awkward in some ways.

  cheers,
rog.

 On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com wrote:
 We moved to GitHub in the hope of lowering the bar to contributors outside
 the team. GitHub is *the* platform and process for open source software.
 This was the logic behind the move. 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 experienced this week). If we value our preferred
 methods of reviewing over keeping to a well known process for outside
 contributors, the best process was launchpad + rietveld. Shouldn't we simply
 return to that.

 Considering we have been successfully using GitHub for several months now,
 using reviewboard is not a necessity. Obviously, I will go with whatever the
 team decides, but I'm concerned that we have moved to reviewboard without
 considering that it undermines (as far as I can see) our primary reason for
 using GitHub.

 Jess

 --
 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: Is ReviewBoard a good thing?

2014-09-19 Thread Dimiter Naydenov
-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 all learnt to live
 with the first issue
 
 On the second, github now does nice side by side diffs.
 
 On the third, it appears reviewboard leaves you solidly to your
 own devices to implement chained proposals.
 
 I'm with Jesse, I vote to stop using reviewboard, I don't think
 it's paying it's way.
+1, Due to all the steps you need (to automate) in order to post the
review correctly, you're on your own w.r.t. chained diffs, finally the
annoying web UI win non-obvious and ways of doing things; I'm a bit
disappointed at what RB brings more than just using GitHub PRs.

 
 
 On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek
 jesse.m...@canonical.com wrote:
 We moved to GitHub in the hope of lowering the bar to
 contributors outside the team. GitHub is *the* platform and
 process for open source software. This was the logic behind the
 move. 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 experienced this
 week). If we value our preferred methods of reviewing over
 keeping to a well known process for outside contributors, the
 best process was launchpad + rietveld. Shouldn't we simply return
 to that.
 
 Considering we have been successfully using GitHub for several
 months now, using reviewboard is not a necessity. Obviously, I
 will go with whatever the team decides, but I'm concerned that we
 have moved to reviewboard without considering that it undermines
 (as far as I can see) our primary reason for using GitHub.
 
 Jess
 
 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify
 settings or unsubscribe at: 
 https://lists.ubuntu.com/mailman/listinfo/juju-dev
 


- -- 
Dimiter Naydenov dimiter.nayde...@canonical.com
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUG+WLAAoJENzxV2TbLzHwbw8H/3a7LlCW4FUYsGklM2/P78+q
8KpjZkNrbSD4PY9CGuRIcOKrT40VCJXMuMlfsaXyIXPktD+zTQGjAjlFMAXaA5El
LUmRIwL4vHJuioNerkTBlgyzWqsyl8KA0M1IKilga+GQk7hhEvPcmWLBQI+Qniz2
+GvjG4xUb+QSsFpL3TIbZC8vMu0vsFU3N73v5LTxhxh3udr0AM8dHBHIuVcMHXMF
1nAs4DbIBDSKoJ5e7vvnKn/h6XiBP2iJNwWZBwnjpKEwXW8fSX7vR16CQDOQd4Pd
3KiDTMc1qC32SqAfpvoOc9oEJad0r/+xFvV1phBAS9X5ry3AuBpOHmDiPB/EwCA=
=n7u4
-END PGP SIGNATURE-

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


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Frank Mueller
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 through a PR. My greatest weakness so far has been the missing
side-by-side diff, thankfully GitHub addressed this.

So I'm with Jesse and will go with the team if we decide to use
ReviewBoard, but I prefer returning to a GitHub based process as it is know
in many other communities too.

mue


On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com
wrote:

 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 to live with
  the first issue
 
  On the second, github now does nice side by side diffs.
 
  On the third, it appears reviewboard leaves you solidly to your own
  devices to implement chained proposals.
 
  I'm with Jesse, I vote to stop using reviewboard, I don't think it's
  paying it's way.

 The main thing I was hoping to get from reviewboard that's
 a constant pain to me in github was the ability to look
 at new changes in the context of old comments, to see
 where and how those comments have been addressed.

 So, assuming reviewboard did address that issue, I'm a
 bit sad but I think Jesse makes a very
 good point about keeping things mainstream.

 I guess there's the potential for some third party tool
 to address my issue above.

 So I agree that it might be better to cut losses here and embrace
 github, even if it is awkward in some ways.

   cheers,
 rog.

  On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com
 wrote:
  We moved to GitHub in the hope of lowering the bar to contributors
 outside
  the team. GitHub is *the* platform and process for open source software.
  This was the logic behind the move. 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 experienced this week). If we value our preferred
  methods of reviewing over keeping to a well known process for outside
  contributors, the best process was launchpad + rietveld. Shouldn't we
 simply
  return to that.
 
  Considering we have been successfully using GitHub for several months
 now,
  using reviewboard is not a necessity. Obviously, I will go with
 whatever the
  team decides, but I'm concerned that we have moved to reviewboard
 without
  considering that it undermines (as far as I can see) our primary reason
 for
  using GitHub.
 
  Jess
 
  --
  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




-- 
** Frank Mueller frank.muel...@canonical.com
** Software Engineer - Juju Development
** Canonical
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Jonathan Aquilina
 

Hey guys. 

Long time lurker with the occasional suggestion. 

I
have an idea for something that might be beneficial to the project as a
whole. Has it been considered about custom coding a review system that
will interface with github hooks and provide what is needed to all juju
dev's and keep 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 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 through a PR. My greatest
weakness so far has been the missing side-by-side diff, thankfully
GitHub addressed this. 
 
 So I'm with Jesse and will go with the team
if we decide to use ReviewBoard, but I prefer returning to a GitHub
based process as it is know in many other communities too.
 
 mue 


 On Fri, Sep 19, 2014 at 9:20 AM, roger peppe
roger.pe...@canonical.com [9] wrote:
 
 On 19 September 2014 01:32,
David Cheney david.che...@canonical.com [1] 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 to live with
  the first issue
 
  On the second,
github now does nice side by side diffs.
 
  On the third, it
appears reviewboard leaves you solidly to your own
  devices to
implement chained proposals.
 
  I'm with Jesse, I vote to stop
using reviewboard, I don't think it's
  paying it's way.
 
 The
main thing I was hoping to get from reviewboard that's
 a constant
pain to me in github was the ability to look
 at new changes in the
context of old comments, to see
 where and how those comments have
been addressed.
 
 So, assuming reviewboard did address that issue,
I'm a
 bit sad but I think Jesse makes a very
 good point about
keeping things mainstream.
 
 I guess there's the potential for some
third party tool
 to address my issue above.
 
 So I agree that it
might be better to cut losses here and embrace
 github, even if it is
awkward in some ways.
 
 cheers,
 rog.
 
  On Fri, Sep 19,
2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com [2] wrote:
 
We moved to GitHub in the hope of lowering the bar to contributors
outside
  the team. GitHub is *the* platform and process for open
source software.
  This was the logic behind the move. 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 experienced this week). If we
value our preferred
  methods of reviewing over keeping to a well
known process for outside
  contributors, the best process was
launchpad + rietveld. Shouldn't we simply
  return to that.
 

 Considering we have been successfully using GitHub for several months
now,
  using reviewboard is not a necessity. Obviously, I will go
with whatever the
  team decides, but I'm concerned that we have
moved to reviewboard without
  considering that it undermines (as
far as I can see) our primary reason for
  using GitHub.
 
 
Jess
 
  --
  Juju-dev mailing list
 
Juju-dev@lists.ubuntu.com [3]
  Modify settings or unsubscribe
at:
  https://lists.ubuntu.com/mailman/listinfo/juju-dev [4]
 

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

Juju-dev mailing list
 Juju-dev@lists.ubuntu.com [7]
 Modify
settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev [8]
 
 -- 
 
 **
Frank Mueller frank.muel...@canonical.com [10] 
 ** Software Engineer
- Juju Development 
 ** Canonical
 

Links:
--
[1]
mailto:david.che...@canonical.com
[2]
mailto:jesse.m...@canonical.com
[3] mailto:Juju-dev@lists.ubuntu.com
[4]
https://lists.ubuntu.com/mailman/listinfo/juju-dev
[5]
mailto:Juju-dev@lists.ubuntu.com
[6]
https://lists.ubuntu.com/mailman/listinfo/juju-dev
[7]
mailto:Juju-dev@lists.ubuntu.com
[8]
https://lists.ubuntu.com/mailman/listinfo/juju-dev
[9]
mailto:roger.pe...@canonical.com
[10]
mailto:frank.muel...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Nate Finch
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 think we should continue using reviewboard until we've had more time to
adjust to it.  Remember, we were ready to abandon github after the first
week, too.

I think tooling can solve most of our problems with complicated workflows.

On Fri, Sep 19, 2014 at 4:41 AM, Jonathan Aquilina jaquil...@eagleeyet.net
wrote:

  Hey guys.

 Long time lurker with the occasional suggestion.

 I have an idea for something that might be beneficial to the project as a
 whole. Has it been considered about custom coding a review system that will
 interface with github hooks and provide what is needed to all juju dev's
 and keep 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 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 through a PR. My greatest weakness so far has been the missing
 side-by-side diff, thankfully GitHub addressed this.

 So I'm with Jesse and will go with the team if we decide to use
 ReviewBoard, but I prefer returning to a GitHub based process as it is know
 in many other communities too.

 mue


 On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com
 wrote:

  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 to live with
  the first issue
 
  On the second, github now does nice side by side diffs.
 
  On the third, it appears reviewboard leaves you solidly to your own
  devices to implement chained proposals.
 
  I'm with Jesse, I vote to stop using reviewboard, I don't think it's
  paying it's way.

 The main thing I was hoping to get from reviewboard that's
 a constant pain to me in github was the ability to look
 at new changes in the context of old comments, to see
 where and how those comments have been addressed.

 So, assuming reviewboard did address that issue, I'm a
 bit sad but I think Jesse makes a very
 good point about keeping things mainstream.

 I guess there's the potential for some third party tool
 to address my issue above.

 So I agree that it might be better to cut losses here and embrace
 github, even if it is awkward in some ways.

   cheers,
 rog.

  On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com
 wrote:
  We moved to GitHub in the hope of lowering the bar to contributors
 outside
  the team. GitHub is *the* platform and process for open source
 software.
  This was the logic behind the move. 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 experienced this week). If we value our
 preferred
  methods of reviewing over keeping to a well known process for outside
  contributors, the best process was launchpad + rietveld. Shouldn't we
 simply
  return to that.
 
  Considering we have been successfully using GitHub for several months
 now,
  using reviewboard is not a necessity. Obviously, I will go with
 whatever the
  team decides, but I'm concerned that we have moved to reviewboard
 without
  considering that it undermines (as far as I can see) our primary
 reason for
  using GitHub.
 
  Jess
 
  --
  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




 --
 ** Frank Mueller frank.muel...@canonical.com
 ** Software Engineer - Juju Development
 ** Canonical


 --
 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: Is ReviewBoard a good thing?

2014-09-19 Thread Jonathan Aquilina
Im more than willing to help improve the work flow for you guys. As well as 
fixup issues you giys feel rb has


Sent from Samsung Mobile

 Original message 
From: Nate Finch nate.fi...@canonical.com 
Date: 19/09/2014  1:32 PM  (GMT+01:00) 
To: Jonathan Aquilina jaquil...@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.  This is really 
important since that can have a big effect on our velocity.

I think we should continue using reviewboard until we've had more time to 
adjust to it.  Remember, we were ready to abandon github after the first week, 
too.

I think tooling can solve most of our problems with complicated workflows.

On Fri, Sep 19, 2014 at 4:41 AM, Jonathan Aquilina jaquil...@eagleeyet.net 
wrote:
Hey guys.

Long time lurker with the occasional suggestion.

I have an idea for something that might be beneficial to the project as a 
whole. Has it been considered about custom coding a review system that will 
interface with github hooks and provide what is needed to all juju dev's and 
keep 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 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 through a PR. My 
greatest weakness so far has been the missing side-by-side diff, thankfully 
GitHub addressed this. 

So I'm with Jesse and will go with the team if we decide to use ReviewBoard, 
but I prefer returning to a GitHub based process as it is know in many other 
communities too.

mue
 

On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com wrote:
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 to live with
 the first issue

 On the second, github now does nice side by side diffs.

 On the third, it appears reviewboard leaves you solidly to your own
 devices to implement chained proposals.

 I'm with Jesse, I vote to stop using reviewboard, I don't think it's
 paying it's way.

The main thing I was hoping to get from reviewboard that's
a constant pain to me in github was the ability to look
at new changes in the context of old comments, to see
where and how those comments have been addressed.

So, assuming reviewboard did address that issue, I'm a
bit sad but I think Jesse makes a very
good point about keeping things mainstream.

I guess there's the potential for some third party tool
to address my issue above.

So I agree that it might be better to cut losses here and embrace
github, even if it is awkward in some ways.

  cheers,
    rog.

 On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com wrote:
 We moved to GitHub in the hope of lowering the bar to contributors outside
 the team. GitHub is *the* platform and process for open source software.
 This was the logic behind the move. 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 experienced this week). If we value our preferred
 methods of reviewing over keeping to a well known process for outside
 contributors, the best process was launchpad + rietveld. Shouldn't we simply
 return to that.

 Considering we have been successfully using GitHub for several months now,
 using reviewboard is not a necessity. Obviously, I will go with whatever the
 team decides, but I'm concerned that we have moved to reviewboard without
 considering that it undermines (as far as I can see) our primary reason for
 using GitHub.

 Jess

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



-- 
** Frank Mueller frank.muel...@canonical.com
** Software Engineer - Juju Development
** Canonical

--
Juju-dev mailing 

Re: Is ReviewBoard a good thing?

2014-09-19 Thread Gabriel Samfira
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 the patchest to gerrit. Something similar for 
RB, would probably simplify things a lot. 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 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 think we should continue using reviewboard until we've had more time to 
adjust to it.  Remember, we were ready to abandon github after the first week, 
too.

I think tooling can solve most of our problems with complicated workflows.

On Fri, Sep 19, 2014 at 4:41 AM, Jonathan Aquilina 
jaquil...@eagleeyet.netmailto:jaquil...@eagleeyet.net wrote:

Hey guys.

Long time lurker with the occasional suggestion.

I have an idea for something that might be beneficial to the project as a 
whole. Has it been considered about custom coding a review system that will 
interface with github hooks and provide what is needed to all juju dev's and 
keep 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 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 through a PR. My 
greatest weakness so far has been the missing side-by-side diff, thankfully 
GitHub addressed this.

So I'm with Jesse and will go with the team if we decide to use ReviewBoard, 
but I prefer returning to a GitHub based process as it is know in many other 
communities too.

mue


On Fri, Sep 19, 2014 at 9:20 AM, roger peppe 
roger.pe...@canonical.commailto:roger.pe...@canonical.com wrote:
On 19 September 2014 01:32, David Cheney 
david.che...@canonical.commailto: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 to live with
 the first issue

 On the second, github now does nice side by side diffs.

 On the third, it appears reviewboard leaves you solidly to your own
 devices to implement chained proposals.

 I'm with Jesse, I vote to stop using reviewboard, I don't think it's
 paying it's way.

The main thing I was hoping to get from reviewboard that's
a constant pain to me in github was the ability to look
at new changes in the context of old comments, to see
where and how those comments have been addressed.

So, assuming reviewboard did address that issue, I'm a
bit sad but I think Jesse makes a very
good point about keeping things mainstream.

I guess there's the potential for some third party tool
to address my issue above.

So I agree that it might be better to cut losses here and embrace
github, even if it is awkward in some ways.

  cheers,
rog.

 On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek 
 jesse.m...@canonical.commailto:jesse.m...@canonical.com wrote:
 We moved to GitHub in the hope of lowering the bar to contributors outside
 the team. GitHub is *the* platform and process for open source software.
 This was the logic behind the move. 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 experienced this week). If we value our preferred
 methods of reviewing over keeping to a well known process for outside
 contributors, the best process was launchpad + rietveld. Shouldn't we simply
 return to that.

 Considering we have been successfully using GitHub for several months now,
 using reviewboard is not a necessity. Obviously, I will go with whatever the
 team decides, but I'm concerned that we have moved to reviewboard without
 considering that it undermines (as far as I can see) our primary reason for
 using GitHub.

 Jess

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.commailto: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.commailto:Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at: 
 

Re: Is ReviewBoard a good thing?

2014-09-19 Thread Katherine Cox-Buday
I don't yet have a strong opinion either way. I do think that since we
invested so much time in getting Review Board set up, we should use it for
a bit longer to see if these are growing pains.

On Fri, Sep 19, 2014 at 7: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 the patchest to gerrit. Something
 similar for RB, would probably simplify things a lot. 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 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 think we should continue using reviewboard until we've had more time
 to adjust to it.  Remember, we were ready to abandon github after the first
 week, too.

  I think tooling can solve most of our problems with complicated
 workflows.

 On Fri, Sep 19, 2014 at 4:41 AM, Jonathan Aquilina 
 jaquil...@eagleeyet.net wrote:

  Hey guys.

 Long time lurker with the occasional suggestion.

 I have an idea for something that might be beneficial to the project as a
 whole. Has it been considered about custom coding a review system that will
 interface with github hooks and provide what is needed to all juju dev's
 and keep 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 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 through a PR. My greatest weakness so far has been the missing
 side-by-side diff, thankfully GitHub addressed this.

  So I'm with Jesse and will go with the team if we decide to use
 ReviewBoard, but I prefer returning to a GitHub based process as it is know
 in many other communities too.

  mue


 On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com
 wrote:

  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 to live with
  the first issue
 
  On the second, github now does nice side by side diffs.
 
  On the third, it appears reviewboard leaves you solidly to your own
  devices to implement chained proposals.
 
  I'm with Jesse, I vote to stop using reviewboard, I don't think it's
  paying it's way.

 The main thing I was hoping to get from reviewboard that's
 a constant pain to me in github was the ability to look
 at new changes in the context of old comments, to see
 where and how those comments have been addressed.

 So, assuming reviewboard did address that issue, I'm a
 bit sad but I think Jesse makes a very
 good point about keeping things mainstream.

 I guess there's the potential for some third party tool
 to address my issue above.

 So I agree that it might be better to cut losses here and embrace
 github, even if it is awkward in some ways.

   cheers,
 rog.

  On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com
 wrote:
  We moved to GitHub in the hope of lowering the bar to contributors
 outside
  the team. GitHub is *the* platform and process for open source
 software.
  This was the logic behind the move. 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 experienced this week). If we value our
 preferred
  methods of reviewing over keeping to a well known process for outside
  contributors, the best process was launchpad + rietveld. Shouldn't we
 simply
  return to that.
 
  Considering we have been successfully using GitHub for several months
 now,
  using reviewboard is not a necessity. Obviously, I will go with
 whatever the
  team decides, but I'm concerned that we have moved to reviewboard
 without
  considering that it undermines (as far as I can see) our primary
 reason for
  using GitHub.
 
  Jess
 
  --
  Juju-dev mailing list
  Juju-dev@lists.ubuntu.com
  Modify settings or 

Re: Is ReviewBoard a good thing?

2014-09-19 Thread Richard Harding
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 to kanban not github. I do that for the same reason. We've got
teams working on 4 different github projects under two different orgs at
the moment. Using the source control as a source seems pretty doomed. You
already have a 3rd party tool to track that, kanban.

Rick

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


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Dimiter Naydenov
-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 this
 said a couple of times but I realized the way I find out what needs
 to be looked at is to go to kanban not github. I do that for the
 same reason. We've got teams working on 4 different github projects
 under two different orgs at the moment. Using the source control as
 a source seems pretty doomed. You already have a 3rd party tool to
 track that, kanban.

+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 in one
place, I tend to work on the main repo mostly, and alternatively you
can check the Notifications page (https://github.com/notifications) to
see all activity.

Dimiter
 
 Rick
 


- -- 
Dimiter Naydenov dimiter.nayde...@canonical.com
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUHDXWAAoJENzxV2TbLzHwV68H/1kJfNtOvaPSeKIc9DheDmUr
ainEU/blIbY4CQe04lybX6vVoK+KZaFwddoeFa17rou7ReDckp3S4yBTZXcD0KO0
QvwYbuqnepWi9pKN3dcuJftknaEE9vLqslWzjTFyZmjS96RGXT3WlR/CrCCZnjUw
Yr7K33ytjcr0oBo8bEk0G0wOkQvwVuvlnNLPPaZF681QyqvODRD+jmgs7SGeUuJu
GS6vLzIppd6xJQiDy72slcLdAcMyPkqCm2jOTosy5ZSMDKHjxgIP0s9uaHmTIJO2
BdZxik0TZfsA7r+DRwhQndvKdmklmcLUQAxp5+oY/nPyGe0s5lZ9PC37p+BtrD8=
=L6g5
-END PGP SIGNATURE-

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


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Eric Snow
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 in one
 place, I tend to work on the main repo mostly, and alternatively you
 can check the Notifications page (https://github.com/notifications) to
 see all activity.

The problem is when your PR in another repo sits there because
everyone tends to work on the main repo mostly.  A unified review
queue solves that quite nicely. :)

-eric

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


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Horacio Duran
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 give it another week
 or 2
  then discuss in the cross teams if we want to keep it or not

 +1

 -eric

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com javascript:;
 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: Is ReviewBoard a good thing?

2014-09-19 Thread Eric Snow
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 is that the real pain points are addressable in the short term.
 Let's give it a chance.

Just to be clear, while I have spent a lot of time on setting up
ReviewBoard and believe it's our best option, I appreciate this
discussion and gladly accept both positive and negative feedback.  If
we decide that ReviewBoard isn't worth it, I'll support the decision
and move on. :)  Furthermore, I recognize that the future of
reviewboard for our team is mostly up to the team leads but ultimately
is driven by the whole team.

-eric

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


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Eric Snow
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 the patchest to gerrit. Something similar
 for RB, would probably simplify things a lot. Chained PR's could probably be
 done by specifying in the commit message something like:

 depends on #PR ID

That would definitely ease the pain.  Even if we have automation of
the main workflow, a git plugin would still help with chained branches
(which github does not support).

-eric

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


Re: Is ReviewBoard a good thing?

2014-09-19 Thread Eric Snow
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 pros and cons.
I'll open a new thread.


 I think that over the last few months we've all learnt to live with
 the first issue

I for one haven't.  On several occasions I have made a comment that I
later realized was not valid, but am not able to simply remove since
it already sent.


 On the second, github now does nice side by side diffs.

Agreed.


 On the third, it appears reviewboard leaves you solidly to your own
 devices to implement chained proposals.

rbt supports it just fine and reviewboard itself supports it (see the
Depends on field on every review request).  What support did you
have in mind?

-eric

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


The Pros and Cons of ReviewBoard.

2014-09-19 Thread Eric Snow
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 of using it (at least relative to
github).  Feel free to expand on any point here or add to them.

-eric

ReviewBoard Pros:

* self-hosted (flexibility, ownership)
* unified review queue with detailed info
* reviews are composed of multiple comments, not just one
* reviews have worklow-supporting metadata (ship-it, issues)
* reviews can be edited as a whole before publishing
* review comments are threaded (provides context)
* customizable (3rd party and custom extensions)
* extensive remote API
* some github integration
* supports chained branches (anti-pattern?)
* allows you to look at new changes in context of old comments
* allows you to look at changes between review request updates
* does not require a PR to exist

ReviewBoard Cons:

* self-hosted (hosting, maintenance, etc.)
* adds manual steps to our workflow
* extra steps increase the barrier to contributing
* not a part of the mainstream github workflow
* requires adjusting to a new tool for most people
* web UI has some usability issues (list?)
* emails formatting is complicated (subjective)

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


Re: The Pros and Cons of ReviewBoard.

2014-09-19 Thread Eric Snow
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 on whether or not we should ditch reviewboard.

 Let's look at the pros and cons of using it (at least relative to
 github).  Feel free to expand on any point here or add to them.

 -eric

 ReviewBoard Pros:

 * self-hosted (flexibility, ownership)
 * unified review queue with detailed info
 * reviews are composed of multiple comments, not just one
 * reviews have worklow-supporting metadata (ship-it, issues)
 * reviews can be edited as a whole before publishing
 * review comments are threaded (provides context)
 * customizable (3rd party and custom extensions)
 * extensive remote API
 * some github integration
 * supports chained branches (anti-pattern?)
 * allows you to look at new changes in context of old comments
 * allows you to look at changes between review request updates
 * does not require a PR to exist

 ReviewBoard Cons:

 * self-hosted (hosting, maintenance, etc.)
 * adds manual steps to our workflow
 * extra steps increase the barrier to contributing
 * not a part of the mainstream github workflow
 * requires adjusting to a new tool for most people
 * web UI has some usability issues (list?)
 * emails formatting is complicated (subjective)

Solutions:

* add integration between github and reviewboard (github webhooks)
  - addresses manual steps (i.e. barrier-to-entry/workflow concerns)
* provide a git plugin that wraps rbt and better supports our workflow
  - addresses complex workflow concerns
* (unlikely) Modify and add to the web UI (via an extension)
  - addresses web UI concerns
* (unlikely) Modify and add to the email formatting (via an extension)
  - addresses email formatting concerns

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


Re: The Pros and Cons of ReviewBoard.

2014-09-19 Thread Jonathan Aquilina
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 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 on whether or not we should ditch reviewboard.

 Let's look at the pros and cons of using it (at least relative to
 github).  Feel free to expand on any point here or add to them.

 -eric

 ReviewBoard Pros:

 * self-hosted (flexibility, ownership)
 * unified review queue with detailed info
 * reviews are composed of multiple comments, not just one
 * reviews have worklow-supporting metadata (ship-it, issues)
 * reviews can be edited as a whole before publishing
 * review comments are threaded (provides context)
 * customizable (3rd party and custom extensions)
 * extensive remote API
 * some github integration
 * supports chained branches (anti-pattern?)
 * allows you to look at new changes in context of old comments
 * allows you to look at changes between review request updates
 * does not require a PR to exist

 ReviewBoard Cons:

 * self-hosted (hosting, maintenance, etc.)
 * adds manual steps to our workflow
 * extra steps increase the barrier to contributing
 * not a part of the mainstream github workflow
 * requires adjusting to a new tool for most people
 * web UI has some usability issues (list?)
 * emails formatting is complicated (subjective)

Solutions:

* add integration between github and reviewboard (github webhooks)
  - addresses manual steps (i.e. barrier-to-entry/workflow concerns)
* provide a git plugin that wraps rbt and better supports our workflow
  - addresses complex workflow concerns
* (unlikely) Modify and add to the web UI (via an extension)
  - addresses web UI concerns
* (unlikely) Modify and add to the email formatting (via an extension)
  - addresses email formatting concerns

-- 
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 stable 1.20.8 is proposed for release

2014-09-19 Thread Curtis Hovey-Canonical
juju-core 1.20.8

A new proposed stable release of Juju, juju-core 1.20.8, is now available.
This release may replace stable 1.20.7 after a period of evaluation. If
no issues are raised about this version, it will released on or after
September 24, 2014.


Getting Juju

juju-core 1.20.8 is available for utopic and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

The proposed packages in this archive use the proposed simple-streams.
You must configure the 'tools-metadata-url' option in your
environments.yaml to use the matching juju tools.

tools-metadata-url: https://streams.canonical.com/juju/proposed/tools

This ensures a clean separation between the stable tools and the proposed
tools. Production environments based on stable juju cannot accidentally
upgrade to a proposed release. The 'tools-metadata-url' option must be set
to clearly state the environment is for evaluating proposed versions.

If you have a environment dedicated to evaluating upgrades of juju you can
switch your testing environment to use the proposed streams like so:

juju set-env
tools-metadata-url=https://streams.canonical.com/juju/proposed/tools

This change may take hours to propagate. You can upgrade when the proposed url
is shown to be in the env.

 juju get-env tools-metadata-url


Notable Changes

This releases addresses stability and performance issues.


Resolved issues

* Maas provider assumes machine uses dhcp for eth0
  Lp 1361374

* Relation-get with invalid relation name panics agent
  Lp 1365412

* Bootstrap on maas fails trying to access cloud-images.ubuntu.com
  Lp 1365135

* Not okforstorage error when deploying local charm
  Lp 1308146

* Add-machine containers should default to latest lts
  Lp 1363971

* Juju add-machine still assumes precise (maas)
  Lp 1315473

* Juju-core client panics with juju set empty string
  Lp 1348829

* --keep-broken option still allows instance to be stopped
  Lp 1365772

* Some third party embedded sources in the source tarball are missing
  dependencies.tsv entries
  Lp 1368321

* Licensing is inconsistent
  Lp 1368358

* Sshstorage fails in non-english locale
  Lp 1367695


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

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


Re: The Pros and Cons of ReviewBoard.

2014-09-19 Thread Matthew Williams
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...@eagleeyet.net wrote:
  I am more than willing to help out wity those modifications

 Cool.  I'll get in touch.

 -eric

 --
 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: The Pros and Cons of ReviewBoard.

2014-09-19 Thread Nate Finch
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 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...@eagleeyet.net wrote:
  I am more than willing to help out wity those modifications

 Cool.  I'll get in touch.

 -eric

 --
 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: Is ReviewBoard a good thing?

2014-09-19 Thread David Cheney
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 to to
 chained proposals.

 It will be worth being extra clear on ReviewBoard's pros and cons.
 I'll open a new thread.


 I think that over the last few months we've all learnt to live with
 the first issue

 I for one haven't.  On several occasions I have made a comment that I
 later realized was not valid, but am not able to simply remove since
 it already sent.


 On the second, github now does nice side by side diffs.

 Agreed.


 On the third, it appears reviewboard leaves you solidly to your own
 devices to implement chained proposals.

 rbt supports it just fine and reviewboard itself supports it (see the
 Depends on field on every review request).  What support did you
 have in mind?

Ian and Tim want whatever they had with launchpad. I never used lp
like that so I never felt the loss; I just propose one branch at a
time and have others waiting in the wings that I can propose as soon
as the predecessor lands.


 -eric

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


Re: The Pros and Cons of ReviewBoard.

2014-09-19 Thread Jonathan Aquilina
 

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 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 [4] wrote:
 
 On
Fri, Sep 19, 2014 at 9:48 AM, Jonathan Aquilina

jaquil...@eagleeyet.net [1] wrote:
  I am more than willing to help
out wity those modifications
 
 Cool. I'll get in touch.
 

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



Links:
--
[1] mailto:jaquil...@eagleeyet.net
[2]
mailto:Juju-dev@lists.ubuntu.com
[3]
https://lists.ubuntu.com/mailman/listinfo/juju-dev
[4]
mailto:eric.s...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: The Pros and Cons of ReviewBoard.

2014-09-19 Thread Jonathan Aquilina
 

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 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 [7] wrote:
 
 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 [4] wrote:
 
 On Fri, Sep 19, 2014 at
9:48 AM, Jonathan Aquilina
 jaquil...@eagleeyet.net [1] wrote:

 I am more than willing to help out wity those modifications
 

Cool. I'll get in touch.
 
 -eric
 
 --
 Juju-dev mailing
list
 Juju-dev@lists.ubuntu.com [2]
 Modify settings or
unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
[3]
 
 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
[5]
 Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev [6]



Links:
--
[1] mailto:jaquil...@eagleeyet.net
[2]
mailto:Juju-dev@lists.ubuntu.com
[3]
https://lists.ubuntu.com/mailman/listinfo/juju-dev
[4]
mailto:eric.s...@canonical.com
[5] mailto:Juju-dev@lists.ubuntu.com
[6]
https://lists.ubuntu.com/mailman/listinfo/juju-dev
[7]
mailto:matthew.willi...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev