Re: Juju client now works properly on all Linuxes

[Tom Barber]

Indeed ramp up the american Marco ramp it up! ;)

On a more mundane note, that is very good news.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 16 September 2016 at 04:21, Marco Ceppi 
wrote:

> This is FANTASTIC news for those using the Snap!
>
> On Thu, Sep 15, 2016 at 10:53 PM Rick Harding 
> wrote:
>
>> Thanks Menno, this is great stuff.
>>
>> On Thu, Sep 15, 2016, 10:35 PM Menno Smits 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> This is just a quick heads up about an improvement that will be in Juju
>>> 2.0 rc1.
>>>
>>> The Juju client has never really worked on flavours of Linux which we
>>> hadn't explicitly added support for (i.e. Ubuntu and Centos). This has now
>>> been fixed: the client will work on any Linux distribution. This has been
>>> tested with Fedora, Debian and Arch.
>>>
>>> Additionally, when using local Juju binaries (i.e. a juju and jujud
>>> which you've built yourself or someone has sent you), checks have been
>>> relaxed allowing a Juju client running on any Linux flavour to bootstrap a
>>> controller running any of the supported Ubuntu series. Previously it wasn't
>>> possible for a client not running a non-Ubuntu distribution to bootstrap a
>>> Juju controller using local Juju binaries.
>>>
>>> Please ask if anything about this is unclear.
>>>
>>> - Menno
>>>
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju client now works properly on all Linuxes

[Marco Ceppi]

This is FANTASTIC news for those using the Snap!

On Thu, Sep 15, 2016 at 10:53 PM Rick Harding 
wrote:

> Thanks Menno, this is great stuff.
>
> On Thu, Sep 15, 2016, 10:35 PM Menno Smits 
> wrote:
>
>> Hi everyone,
>>
>> This is just a quick heads up about an improvement that will be in Juju
>> 2.0 rc1.
>>
>> The Juju client has never really worked on flavours of Linux which we
>> hadn't explicitly added support for (i.e. Ubuntu and Centos). This has now
>> been fixed: the client will work on any Linux distribution. This has been
>> tested with Fedora, Debian and Arch.
>>
>> Additionally, when using local Juju binaries (i.e. a juju and jujud which
>> you've built yourself or someone has sent you), checks have been relaxed
>> allowing a Juju client running on any Linux flavour to bootstrap a
>> controller running any of the supported Ubuntu series. Previously it wasn't
>> possible for a client not running a non-Ubuntu distribution to bootstrap a
>> Juju controller using local Juju binaries.
>>
>> Please ask if anything about this is unclear.
>>
>> - Menno
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju client now works properly on all Linuxes

[Rick Harding]

Thanks Menno, this is great stuff.

On Thu, Sep 15, 2016, 10:35 PM Menno Smits 
wrote:

> Hi everyone,
>
> This is just a quick heads up about an improvement that will be in Juju
> 2.0 rc1.
>
> The Juju client has never really worked on flavours of Linux which we
> hadn't explicitly added support for (i.e. Ubuntu and Centos). This has now
> been fixed: the client will work on any Linux distribution. This has been
> tested with Fedora, Debian and Arch.
>
> Additionally, when using local Juju binaries (i.e. a juju and jujud which
> you've built yourself or someone has sent you), checks have been relaxed
> allowing a Juju client running on any Linux flavour to bootstrap a
> controller running any of the supported Ubuntu series. Previously it wasn't
> possible for a client not running a non-Ubuntu distribution to bootstrap a
> Juju controller using local Juju binaries.
>
> Please ask if anything about this is unclear.
>
> - Menno
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju client now works properly on all Linuxes

[Menno Smits]

Hi everyone,

This is just a quick heads up about an improvement that will be in Juju 2.0
rc1.

The Juju client has never really worked on flavours of Linux which we
hadn't explicitly added support for (i.e. Ubuntu and Centos). This has now
been fixed: the client will work on any Linux distribution. This has been
tested with Fedora, Debian and Arch.

Additionally, when using local Juju binaries (i.e. a juju and jujud which
you've built yourself or someone has sent you), checks have been relaxed
allowing a Juju client running on any Linux flavour to bootstrap a
controller running any of the supported Ubuntu series. Previously it wasn't
possible for a client not running a non-Ubuntu distribution to bootstrap a
Juju controller using local Juju binaries.

Please ask if anything about this is unclear.

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

Re: Reviews on Github

[Ian Booth]

On 16/09/16 03:50, Nate Finch wrote:
> Reviewboard goes down a couple times a month, usually from lack of disk
> space or some other BS.  According to a source knowledgeable with these
> matters, the charm was rushed out, and the agent for that machine is down
> anyway, so we're kinda just waiting for the other shoe to drop.
> 
> As for the process things that Ian mentioned, most of those can be
> addressed with a sprinkling of convention.  Marking things as issues could
> just be adding :x: to the first line (github even pops up suggestions and
> auto-completes), thusly:
> 
> [image: :x:]This will cause a race condition
> 
> And if you want to indicate you're dropping a suggestion, you can use :-1:
>  which gives you a thumbs down:
> 
> [image: :-1:] I ran the race detector and it's fine.
> 
> It won't give you the cumulative "what's left to fix" at the top of the
> page, like reviewboard... but for me, I never directly read that, anyway,
> just used it to see if there were zero or non-zero comments left.
>

If we want to do a trial, and we acknowledge that there are functional gaps, and
we are prepared to work around those using convention, then we should document
what those conventions are so that everyone takes a consistent approach.


> As for the inline comments in the code - there's a checkbox to hide them
> all.  It's not quite as convenient as the gutter indicators per-comment,
> but it's sufficient, I think.
> 

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

Re: Reviews on Github

[Ian Booth]

On 16/09/16 08:54, Anastasia Macmood wrote:
> On 16/09/16 08:02, Ian Booth wrote:
>> Another data point - in the past, when we have had PRs which touch a lot of
>> files (eg change the import path for a dependency), review board paginates 
>> the
>> diff so it's much easier to manage, whereas I've seen github actually 
>> truncate
>> what it displays because the diff is "too large". Hopefully this will no 
>> longer
>> be an issue, or else we won't be able to review such changes in the future.
> This is perfect to reduce the size of our proposals to manageable :)
>>

The point is that that's not always possible. The example given was where we
need to update import paths due to a dependency change. That has to be done all
in one go. There are other occasions as well where sometimes a mechanical change
needs to touch a lot of files in the one PR. We just need to be sure that any RB
replacement caters for those scenarios.


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

Re: Reviews on Github

[Anastasia Macmood]

On 16/09/16 08:02, Ian Booth wrote:
> Another data point - in the past, when we have had PRs which touch a lot of
> files (eg change the import path for a dependency), review board paginates the
> diff so it's much easier to manage, whereas I've seen github actually truncate
> what it displays because the diff is "too large". Hopefully this will no 
> longer
> be an issue, or else we won't be able to review such changes in the future.
This is perfect to reduce the size of our proposals to manageable :)
>
> On 16/09/16 07:53, Menno Smits wrote:
>> Although I share some of Ian's concerns, I think the reduced moving parts,
>> improved reliability, reduced maintenance, easier experience for outside
>> contributors and better handling of file moves are pretty big wins. The
>> rendering of diffs on Github is a whole lot nicer as well.
>>
>> I'm +1 for trialling the new review system on Github for a couple of weeks
>> as per Andrew's suggestion.
>>
>> On 16 September 2016 at 05:50, Nate Finch  wrote:
>>
>>> Reviewboard goes down a couple times a month, usually from lack of disk
>>> space or some other BS.  According to a source knowledgeable with these
>>> matters, the charm was rushed out, and the agent for that machine is down
>>> anyway, so we're kinda just waiting for the other shoe to drop.
>>>
>>> As for the process things that Ian mentioned, most of those can be
>>> addressed with a sprinkling of convention.  Marking things as issues could
>>> just be adding :x: to the first line (github even pops up suggestions and
>>> auto-completes), thusly:
>>>
>>> [image: :x:]This will cause a race condition
>>>
>>> And if you want to indicate you're dropping a suggestion, you can use :-1:
>>>  which gives you a thumbs down:
>>>
>>> [image: :-1:] I ran the race detector and it's fine.
>>>
>>> It won't give you the cumulative "what's left to fix" at the top of the
>>> page, like reviewboard... but for me, I never directly read that, anyway,
>>> just used it to see if there were zero or non-zero comments left.
>>>
>>> As for the inline comments in the code - there's a checkbox to hide them
>>> all.  It's not quite as convenient as the gutter indicators per-comment,
>>> but it's sufficient, I think.
>>>
>>> On Wed, Sep 14, 2016 at 6:43 PM Ian Booth  wrote:
>>>

 On 15/09/16 08:22, Rick Harding wrote:
> I think that the issue is that someone has to maintain the RB and the
> cost/time spent on that does not seem commensurate with the bonus
 features
> in my experience.
>
 The maintenance is not that great. We have SSO using github credentials so
 there's really no day to day works IIANM. As a team, we do many, many
 reviews
 per day, and the features I outlined are significant and things I (and I
 assume
 others) rely on. Don't under estimate the value in knowing why a comment
 was
 rejected and being able to properly track that. Or having review comments
 collapsed as a gutter indicated so you can browse the code and still know
 that
 there's a comment there. With github, you can hide the comments but
 there's no
 gutter indicator. All these things add up to a lot.


> On Wed, Sep 14, 2016 at 6:13 PM Ian Booth 
 wrote:
>> One thing review board does better is use gutter indicators so as not
 to
>> interrupt the flow of reading the code with huge comment blocks. It
 also
>> seems
>> much better at allowing previous commits with comments to be viewed in
>> their
>> entirety. And it allows the reviewer to differentiate between issues
 and
>> comments (ie fix this vs take note of this), plus it allows the notion
 of
>> marking stuff as fixed vs dropped, with a reason for dropping if
 needed.
>> So the
>> github improvements are nice but there's still a large and significant
 gap
>> that
>> is yet to be filled. I for one would miss all the features reviewboard
>> offers.
>> Unless there's a way of doing the same thing in github that I'm not
 aware
>> of.
>>
>> On 15/09/16 07:22, Tim Penhey wrote:
>>> I'm +1 if we can remove the extra tools and we don't get email per
>> comment.
>>> On 15/09/16 08:03, Nate Finch wrote:
 In case you missed it, Github rolled out a new review process.  It
 basically works just like reviewboard does, where you start a review,
 batch up comments, then post the review as a whole, so you don't just
 write a bunch of disconnected comments (and get one email per review,
 not per comment).  The only features reviewboard has is the edge case
 stuff that we rarely use:  like using rbt to post a review from a
 random
 diff that is not connected directly to a github PR. I think that is
 easy
 enough to give up in order to get the benefit of not needing an
 

Re: Reviews on Github

[Ian Booth]

Another data point - in the past, when we have had PRs which touch a lot of
files (eg change the import path for a dependency), review board paginates the
diff so it's much easier to manage, whereas I've seen github actually truncate
what it displays because the diff is "too large". Hopefully this will no longer
be an issue, or else we won't be able to review such changes in the future.

On 16/09/16 07:53, Menno Smits wrote:
> Although I share some of Ian's concerns, I think the reduced moving parts,
> improved reliability, reduced maintenance, easier experience for outside
> contributors and better handling of file moves are pretty big wins. The
> rendering of diffs on Github is a whole lot nicer as well.
> 
> I'm +1 for trialling the new review system on Github for a couple of weeks
> as per Andrew's suggestion.
> 
> On 16 September 2016 at 05:50, Nate Finch  wrote:
> 
>> Reviewboard goes down a couple times a month, usually from lack of disk
>> space or some other BS.  According to a source knowledgeable with these
>> matters, the charm was rushed out, and the agent for that machine is down
>> anyway, so we're kinda just waiting for the other shoe to drop.
>>
>> As for the process things that Ian mentioned, most of those can be
>> addressed with a sprinkling of convention.  Marking things as issues could
>> just be adding :x: to the first line (github even pops up suggestions and
>> auto-completes), thusly:
>>
>> [image: :x:]This will cause a race condition
>>
>> And if you want to indicate you're dropping a suggestion, you can use :-1:
>>  which gives you a thumbs down:
>>
>> [image: :-1:] I ran the race detector and it's fine.
>>
>> It won't give you the cumulative "what's left to fix" at the top of the
>> page, like reviewboard... but for me, I never directly read that, anyway,
>> just used it to see if there were zero or non-zero comments left.
>>
>> As for the inline comments in the code - there's a checkbox to hide them
>> all.  It's not quite as convenient as the gutter indicators per-comment,
>> but it's sufficient, I think.
>>
>> On Wed, Sep 14, 2016 at 6:43 PM Ian Booth  wrote:
>>
>>>
>>>
>>> On 15/09/16 08:22, Rick Harding wrote:
 I think that the issue is that someone has to maintain the RB and the
 cost/time spent on that does not seem commensurate with the bonus
>>> features
 in my experience.

>>>
>>> The maintenance is not that great. We have SSO using github credentials so
>>> there's really no day to day works IIANM. As a team, we do many, many
>>> reviews
>>> per day, and the features I outlined are significant and things I (and I
>>> assume
>>> others) rely on. Don't under estimate the value in knowing why a comment
>>> was
>>> rejected and being able to properly track that. Or having review comments
>>> collapsed as a gutter indicated so you can browse the code and still know
>>> that
>>> there's a comment there. With github, you can hide the comments but
>>> there's no
>>> gutter indicator. All these things add up to a lot.
>>>
>>>
 On Wed, Sep 14, 2016 at 6:13 PM Ian Booth 
>>> wrote:

> One thing review board does better is use gutter indicators so as not
>>> to
> interrupt the flow of reading the code with huge comment blocks. It
>>> also
> seems
> much better at allowing previous commits with comments to be viewed in
> their
> entirety. And it allows the reviewer to differentiate between issues
>>> and
> comments (ie fix this vs take note of this), plus it allows the notion
>>> of
> marking stuff as fixed vs dropped, with a reason for dropping if
>>> needed.
> So the
> github improvements are nice but there's still a large and significant
>>> gap
> that
> is yet to be filled. I for one would miss all the features reviewboard
> offers.
> Unless there's a way of doing the same thing in github that I'm not
>>> aware
> of.
>
> On 15/09/16 07:22, Tim Penhey wrote:
>> I'm +1 if we can remove the extra tools and we don't get email per
> comment.
>>
>> On 15/09/16 08:03, Nate Finch wrote:
>>> In case you missed it, Github rolled out a new review process.  It
>>> basically works just like reviewboard does, where you start a review,
>>> batch up comments, then post the review as a whole, so you don't just
>>> write a bunch of disconnected comments (and get one email per review,
>>> not per comment).  The only features reviewboard has is the edge case
>>> stuff that we rarely use:  like using rbt to post a review from a
>>> random
>>> diff that is not connected directly to a github PR. I think that is
>>> easy
>>> enough to give up in order to get the benefit of not needing an
>>> entirely
>>> separate system to handle reviews.
>>>
>>> I made a little test review on one PR here, and the UX was almost
>>> exactly like working in reviewboard:
> 

Re: Reviews on Github

[Menno Smits]

Although I share some of Ian's concerns, I think the reduced moving parts,
improved reliability, reduced maintenance, easier experience for outside
contributors and better handling of file moves are pretty big wins. The
rendering of diffs on Github is a whole lot nicer as well.

I'm +1 for trialling the new review system on Github for a couple of weeks
as per Andrew's suggestion.

On 16 September 2016 at 05:50, Nate Finch  wrote:

> Reviewboard goes down a couple times a month, usually from lack of disk
> space or some other BS.  According to a source knowledgeable with these
> matters, the charm was rushed out, and the agent for that machine is down
> anyway, so we're kinda just waiting for the other shoe to drop.
>
> As for the process things that Ian mentioned, most of those can be
> addressed with a sprinkling of convention.  Marking things as issues could
> just be adding :x: to the first line (github even pops up suggestions and
> auto-completes), thusly:
>
> [image: :x:]This will cause a race condition
>
> And if you want to indicate you're dropping a suggestion, you can use :-1:
>  which gives you a thumbs down:
>
> [image: :-1:] I ran the race detector and it's fine.
>
> It won't give you the cumulative "what's left to fix" at the top of the
> page, like reviewboard... but for me, I never directly read that, anyway,
> just used it to see if there were zero or non-zero comments left.
>
> As for the inline comments in the code - there's a checkbox to hide them
> all.  It's not quite as convenient as the gutter indicators per-comment,
> but it's sufficient, I think.
>
> On Wed, Sep 14, 2016 at 6:43 PM Ian Booth  wrote:
>
>>
>>
>> On 15/09/16 08:22, Rick Harding wrote:
>> > I think that the issue is that someone has to maintain the RB and the
>> > cost/time spent on that does not seem commensurate with the bonus
>> features
>> > in my experience.
>> >
>>
>> The maintenance is not that great. We have SSO using github credentials so
>> there's really no day to day works IIANM. As a team, we do many, many
>> reviews
>> per day, and the features I outlined are significant and things I (and I
>> assume
>> others) rely on. Don't under estimate the value in knowing why a comment
>> was
>> rejected and being able to properly track that. Or having review comments
>> collapsed as a gutter indicated so you can browse the code and still know
>> that
>> there's a comment there. With github, you can hide the comments but
>> there's no
>> gutter indicator. All these things add up to a lot.
>>
>>
>> > On Wed, Sep 14, 2016 at 6:13 PM Ian Booth 
>> wrote:
>> >
>> >> One thing review board does better is use gutter indicators so as not
>> to
>> >> interrupt the flow of reading the code with huge comment blocks. It
>> also
>> >> seems
>> >> much better at allowing previous commits with comments to be viewed in
>> >> their
>> >> entirety. And it allows the reviewer to differentiate between issues
>> and
>> >> comments (ie fix this vs take note of this), plus it allows the notion
>> of
>> >> marking stuff as fixed vs dropped, with a reason for dropping if
>> needed.
>> >> So the
>> >> github improvements are nice but there's still a large and significant
>> gap
>> >> that
>> >> is yet to be filled. I for one would miss all the features reviewboard
>> >> offers.
>> >> Unless there's a way of doing the same thing in github that I'm not
>> aware
>> >> of.
>> >>
>> >> On 15/09/16 07:22, Tim Penhey wrote:
>> >>> I'm +1 if we can remove the extra tools and we don't get email per
>> >> comment.
>> >>>
>> >>> On 15/09/16 08:03, Nate Finch wrote:
>>  In case you missed it, Github rolled out a new review process.  It
>>  basically works just like reviewboard does, where you start a review,
>>  batch up comments, then post the review as a whole, so you don't just
>>  write a bunch of disconnected comments (and get one email per review,
>>  not per comment).  The only features reviewboard has is the edge case
>>  stuff that we rarely use:  like using rbt to post a review from a
>> random
>>  diff that is not connected directly to a github PR. I think that is
>> easy
>>  enough to give up in order to get the benefit of not needing an
>> entirely
>>  separate system to handle reviews.
>> 
>>  I made a little test review on one PR here, and the UX was almost
>>  exactly like working in reviewboard:
>> >> https://github.com/juju/juju/pull/6234
>> 
>>  There may be important edge cases I'm missing, but I think it's worth
>>  looking into.
>> 
>>  -Nate
>> 
>> 
>> >>>
>> >>
>> >> --
>> >> 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/
>> 

Re: Reviews on Github

[Nate Finch]

Reviewboard goes down a couple times a month, usually from lack of disk
space or some other BS.  According to a source knowledgeable with these
matters, the charm was rushed out, and the agent for that machine is down
anyway, so we're kinda just waiting for the other shoe to drop.

As for the process things that Ian mentioned, most of those can be
addressed with a sprinkling of convention.  Marking things as issues could
just be adding :x: to the first line (github even pops up suggestions and
auto-completes), thusly:

[image: :x:]This will cause a race condition

And if you want to indicate you're dropping a suggestion, you can use :-1:
 which gives you a thumbs down:

[image: :-1:] I ran the race detector and it's fine.

It won't give you the cumulative "what's left to fix" at the top of the
page, like reviewboard... but for me, I never directly read that, anyway,
just used it to see if there were zero or non-zero comments left.

As for the inline comments in the code - there's a checkbox to hide them
all.  It's not quite as convenient as the gutter indicators per-comment,
but it's sufficient, I think.

On Wed, Sep 14, 2016 at 6:43 PM Ian Booth  wrote:

>
>
> On 15/09/16 08:22, Rick Harding wrote:
> > I think that the issue is that someone has to maintain the RB and the
> > cost/time spent on that does not seem commensurate with the bonus
> features
> > in my experience.
> >
>
> The maintenance is not that great. We have SSO using github credentials so
> there's really no day to day works IIANM. As a team, we do many, many
> reviews
> per day, and the features I outlined are significant and things I (and I
> assume
> others) rely on. Don't under estimate the value in knowing why a comment
> was
> rejected and being able to properly track that. Or having review comments
> collapsed as a gutter indicated so you can browse the code and still know
> that
> there's a comment there. With github, you can hide the comments but
> there's no
> gutter indicator. All these things add up to a lot.
>
>
> > On Wed, Sep 14, 2016 at 6:13 PM Ian Booth 
> wrote:
> >
> >> One thing review board does better is use gutter indicators so as not to
> >> interrupt the flow of reading the code with huge comment blocks. It also
> >> seems
> >> much better at allowing previous commits with comments to be viewed in
> >> their
> >> entirety. And it allows the reviewer to differentiate between issues and
> >> comments (ie fix this vs take note of this), plus it allows the notion
> of
> >> marking stuff as fixed vs dropped, with a reason for dropping if needed.
> >> So the
> >> github improvements are nice but there's still a large and significant
> gap
> >> that
> >> is yet to be filled. I for one would miss all the features reviewboard
> >> offers.
> >> Unless there's a way of doing the same thing in github that I'm not
> aware
> >> of.
> >>
> >> On 15/09/16 07:22, Tim Penhey wrote:
> >>> I'm +1 if we can remove the extra tools and we don't get email per
> >> comment.
> >>>
> >>> On 15/09/16 08:03, Nate Finch wrote:
>  In case you missed it, Github rolled out a new review process.  It
>  basically works just like reviewboard does, where you start a review,
>  batch up comments, then post the review as a whole, so you don't just
>  write a bunch of disconnected comments (and get one email per review,
>  not per comment).  The only features reviewboard has is the edge case
>  stuff that we rarely use:  like using rbt to post a review from a
> random
>  diff that is not connected directly to a github PR. I think that is
> easy
>  enough to give up in order to get the benefit of not needing an
> entirely
>  separate system to handle reviews.
> 
>  I made a little test review on one PR here, and the UX was almost
>  exactly like working in reviewboard:
> >> https://github.com/juju/juju/pull/6234
> 
>  There may be important edge cases I'm missing, but I think it's worth
>  looking into.
> 
>  -Nate
> 
> 
> >>>
> >>
> >> --
> >> 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

no beta/rc release today, schedule is Tues Sept 20th

[Rick Harding]

tl;dr the Juju RC1 is scheduled to be built and released on Tues, Sept 20th

The team would like to let everyone know that there will not be a beta or
RC1 today as usual. The team has been working very hard to address the
outstanding critical issues that need to be corrected before we claim that
Juju 2.0 is ready for RC status. In particular we’re working hard to
address a known issue with networking on MAAS [1], and an issue in the
credential management work. We don’t feel comfortable going to RC with
these two issue outstanding. The team is working quickly to wrap the fix up
and once that is done we’ll be building our RC release.

If you have any questions or concerns please don’t hesitate to reach out to
myself or the team. We’re all very excited and chomping at the bit to get
2.0 out to all of you.

1: https://bugs.launchpad.net/juju/+bug/1566791
Rick
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju