Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

I guess it's all about this bit of the license:

The Software shall be used for Good, not Evil

which doesn't fit in legalese speak :)


> On 24.11.2016 г., at 17:27, Svetoslav Neykov 
>  wrote:
> 
> Thanks for the heads up Richard. I'll check whether we are using it.
> 
> Svet.
> 
> 
>> On 24.11.2016 г., at 16:56, Richard Downer  wrote:
>> 
>> Svet,
>> 
>> There's a discussion going on elsewhere in ASF[1] about The JSON License[2]
>> - it was previously acceptable to ASF and was on the Category A list[3].
>> However, it's been realised that the decision to place it in Category A was
>> incorrect, and it has now been moved to Category X. This means that
>> software covered by The JSON License must not be a transitive dependency of
>> Apache software releases.
>> 
>> I believe that the software this affects is the "json.org" or "org.json"
>> Java JSON library. I don't think that we use this, but it's possible that
>> it's a transitive dependency.
>> 
>> If this comes up in your LICENSE rework then we'll need to take some action
>> on it - we have a grace period so it doesn't necessarily have to be
>> replaced this release, although we would need to update NOTICE. However
>> there exist drop-in compatible replacements so it may be easier to just
>> deal with it now.
>> 
>> If you'd like me to link you to more of the discussion then I can do that.
>> 
>> Richard.
>> 
>> [1]
>> https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E
>> [2]http://www.json.org/license.html
>> [3]https://www.apache.org/legal/resolved#category-a
>> 
>> On 24 November 2016 at 13:52, Svetoslav Neykov <
>> svetoslav.ney...@cloudsoftcorp.com> wrote:
>> 
>>> That's some good news. Thanks for taking the time to look at this Andrea.
>>> I also have some progress to share. Today I was finally able to build
>>> Brooklyn with all tests passing (consistently at that) - on a branch that
>>> had all my recent PRs. Thanks Geoff for reviewing and merging all of them.
>>> I'm currently checking whether our LICENSE files need an update because of
>>> updated dependencies and fixing the corresponding scripts to work with the
>>> current project structure. Next will turn my attention to testing the
>>> jclouds 1.9.3 PRs. As soon as they are merged we can have our first RC.
>>> 
>>> Also would be nice to include a proper fix for what #452 [1] tried to
>>> solve (but failed at).
>>> Any other suggestions for PRs to include in the RC are welcome.
>>> 
>>> Our change log needs some love so any help there will be greatly
>>> appreciated.
>>> 
>>> Svet.
>>> 
 On 24.11.2016 г., at 15:16, Andrea Turli 
>>> wrote:
 
 Hi
 
 jclouds 1.9.3 is officially out -- see
 http://markmail.org/thread/qlapnppmfbilje7p for more details
 
 
 
 FYI @bostko already created this PR to bump jclouds version
 https://github.com/apache/brooklyn-server/pull/457
 
 I've generated the dependency:list from tag rel/jclouds-1.9.2 and
 rel/jclouds-1.9.3 from jclouds/jclouds repos (see
 https://gist.github.com/andreaturli/b7c178519ab4d029d562643426a2738d and
 https://gist.github.com/andreaturli/8d54e4340ef0a4c650022396b4b54b89)
>>> and
 apart from org.apache.jclouds versions I can't see any new version for
>>> the
 transitive dependencies.
 
 
 
 I've also checked the swift vs openstack-swift issue when targeting the
 brooklyn persistence to IBM SoftLayer Object Storage: it works fine with
 jclouds 1.9.3 and jclouds 2.0.0 so this shouldn't be an issue for the
 release. (see https://github.com/jclouds/jclouds-examples/pull/90)
 
 HTH,
 Andrea
 
 On 18 November 2016 at 12:19, Andrea Turli >> com>
 wrote:
 
> Hi there,
> 
> I've released the Apache jclouds 1.9.3-rc1 (see [1] and [2] for more
> details)
> 
> Please download, test and vote if you can!
> 
> Andrea
> 
> [1]: https://lists.apache.org/thread.html/
>>> 42f3a91008890939cf344f35320f86
> bcc48f814119655d7347c9bcca@%3Cdev.jclouds.apache.org%3E
> [2]: https://lists.apache.org/thread.html/
>>> 94981b8f456785ffea640af3be9207
> 103bb4b7ee2f6d5bb783e98c2c@%3Cdev.jclouds.apache.org%3E
> 
> On 17 November 2016 at 19:01, Duncan Johnston Watt  cloudsoftcorp.com> wrote:
> 
>> +1 Andrea thanks
>> 
>> Duncan Johnston-Watt
>> CEO | Cloudsoft Corporation
>> 
>> Twitter | @duncanjw
>> Mobile | +44 777 190 2653
>> Skype | duncan_johnstonwatt
>> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
>> 
>> On 17 November 2016 at 06:09, Aled Sage  wrote:
>> 
>>> +1, sounds great - thanks Andrea!
>>> 
>>> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or

Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

Thanks for the heads up Richard. I'll check whether we are using it.

Svet.


> On 24.11.2016 г., at 16:56, Richard Downer  wrote:
> 
> Svet,
> 
> There's a discussion going on elsewhere in ASF[1] about The JSON License[2]
> - it was previously acceptable to ASF and was on the Category A list[3].
> However, it's been realised that the decision to place it in Category A was
> incorrect, and it has now been moved to Category X. This means that
> software covered by The JSON License must not be a transitive dependency of
> Apache software releases.
> 
> I believe that the software this affects is the "json.org" or "org.json"
> Java JSON library. I don't think that we use this, but it's possible that
> it's a transitive dependency.
> 
> If this comes up in your LICENSE rework then we'll need to take some action
> on it - we have a grace period so it doesn't necessarily have to be
> replaced this release, although we would need to update NOTICE. However
> there exist drop-in compatible replacements so it may be easier to just
> deal with it now.
> 
> If you'd like me to link you to more of the discussion then I can do that.
> 
> Richard.
> 
> [1]
> https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E
> [2]http://www.json.org/license.html
> [3]https://www.apache.org/legal/resolved#category-a
> 
> On 24 November 2016 at 13:52, Svetoslav Neykov <
> svetoslav.ney...@cloudsoftcorp.com> wrote:
> 
>> That's some good news. Thanks for taking the time to look at this Andrea.
>> I also have some progress to share. Today I was finally able to build
>> Brooklyn with all tests passing (consistently at that) - on a branch that
>> had all my recent PRs. Thanks Geoff for reviewing and merging all of them.
>> I'm currently checking whether our LICENSE files need an update because of
>> updated dependencies and fixing the corresponding scripts to work with the
>> current project structure. Next will turn my attention to testing the
>> jclouds 1.9.3 PRs. As soon as they are merged we can have our first RC.
>> 
>> Also would be nice to include a proper fix for what #452 [1] tried to
>> solve (but failed at).
>> Any other suggestions for PRs to include in the RC are welcome.
>> 
>> Our change log needs some love so any help there will be greatly
>> appreciated.
>> 
>> Svet.
>> 
>>> On 24.11.2016 г., at 15:16, Andrea Turli 
>> wrote:
>>> 
>>> Hi
>>> 
>>> jclouds 1.9.3 is officially out -- see
>>> http://markmail.org/thread/qlapnppmfbilje7p for more details
>>> 
>>> 
>>> 
>>> FYI @bostko already created this PR to bump jclouds version
>>> https://github.com/apache/brooklyn-server/pull/457
>>> 
>>> I've generated the dependency:list from tag rel/jclouds-1.9.2 and
>>> rel/jclouds-1.9.3 from jclouds/jclouds repos (see
>>> https://gist.github.com/andreaturli/b7c178519ab4d029d562643426a2738d and
>>> https://gist.github.com/andreaturli/8d54e4340ef0a4c650022396b4b54b89)
>> and
>>> apart from org.apache.jclouds versions I can't see any new version for
>> the
>>> transitive dependencies.
>>> 
>>> 
>>> 
>>> I've also checked the swift vs openstack-swift issue when targeting the
>>> brooklyn persistence to IBM SoftLayer Object Storage: it works fine with
>>> jclouds 1.9.3 and jclouds 2.0.0 so this shouldn't be an issue for the
>>> release. (see https://github.com/jclouds/jclouds-examples/pull/90)
>>> 
>>> HTH,
>>> Andrea
>>> 
>>> On 18 November 2016 at 12:19, Andrea Turli > com>
>>> wrote:
>>> 
 Hi there,
 
 I've released the Apache jclouds 1.9.3-rc1 (see [1] and [2] for more
 details)
 
 Please download, test and vote if you can!
 
 Andrea
 
 [1]: https://lists.apache.org/thread.html/
>> 42f3a91008890939cf344f35320f86
 bcc48f814119655d7347c9bcca@%3Cdev.jclouds.apache.org%3E
 [2]: https://lists.apache.org/thread.html/
>> 94981b8f456785ffea640af3be9207
 103bb4b7ee2f6d5bb783e98c2c@%3Cdev.jclouds.apache.org%3E
 
 On 17 November 2016 at 19:01, Duncan Johnston Watt  wrote:
 
> +1 Andrea thanks
> 
> Duncan Johnston-Watt
> CEO | Cloudsoft Corporation
> 
> Twitter | @duncanjw
> Mobile | +44 777 190 2653
> Skype | duncan_johnstonwatt
> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
> 
> On 17 November 2016 at 06:09, Aled Sage  wrote:
> 
>> +1, sounds great - thanks Andrea!
>> 
>> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or
>> 2.0.0)
>> that we want, such as an OutOfMemoryError deploying to Softlayer [1].
>> 
>> It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds
>> 1.9.3
>> release.
>> 
>> In the meantime, we should still get our own house in order by doing
>> the
>> first of the steps below (i.e. dealing with open PRs; ensuring no-one
> 

Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

That's some good news. Thanks for taking the time to look at this Andrea.
I also have some progress to share. Today I was finally able to build Brooklyn 
with all tests passing (consistently at that) - on a branch that had all my 
recent PRs. Thanks Geoff for reviewing and merging all of them.
I'm currently checking whether our LICENSE files need an update because of 
updated dependencies and fixing the corresponding scripts to work with the 
current project structure. Next will turn my attention to testing the jclouds 
1.9.3 PRs. As soon as they are merged we can have our first RC.

Also would be nice to include a proper fix for what #452 [1] tried to solve 
(but failed at).
Any other suggestions for PRs to include in the RC are welcome.

Our change log needs some love so any help there will be greatly appreciated.

Svet.

> On 24.11.2016 г., at 15:16, Andrea Turli  
> wrote:
> 
> Hi
> 
> jclouds 1.9.3 is officially out -- see
> http://markmail.org/thread/qlapnppmfbilje7p for more details
> 
> 
> 
> FYI @bostko already created this PR to bump jclouds version
> https://github.com/apache/brooklyn-server/pull/457
> 
> I've generated the dependency:list from tag rel/jclouds-1.9.2 and
> rel/jclouds-1.9.3 from jclouds/jclouds repos (see
> https://gist.github.com/andreaturli/b7c178519ab4d029d562643426a2738d and
> https://gist.github.com/andreaturli/8d54e4340ef0a4c650022396b4b54b89) and
> apart from org.apache.jclouds versions I can't see any new version for the
> transitive dependencies.
> 
> 
> 
> I've also checked the swift vs openstack-swift issue when targeting the
> brooklyn persistence to IBM SoftLayer Object Storage: it works fine with
> jclouds 1.9.3 and jclouds 2.0.0 so this shouldn't be an issue for the
> release. (see https://github.com/jclouds/jclouds-examples/pull/90)
> 
> HTH,
> Andrea
> 
> On 18 November 2016 at 12:19, Andrea Turli 
> wrote:
> 
>> Hi there,
>> 
>> I've released the Apache jclouds 1.9.3-rc1 (see [1] and [2] for more
>> details)
>> 
>> Please download, test and vote if you can!
>> 
>> Andrea
>> 
>> [1]: https://lists.apache.org/thread.html/42f3a91008890939cf344f35320f86
>> bcc48f814119655d7347c9bcca@%3Cdev.jclouds.apache.org%3E
>> [2]: https://lists.apache.org/thread.html/94981b8f456785ffea640af3be9207
>> 103bb4b7ee2f6d5bb783e98c2c@%3Cdev.jclouds.apache.org%3E
>> 
>> On 17 November 2016 at 19:01, Duncan Johnston Watt > cloudsoftcorp.com> wrote:
>> 
>>> +1 Andrea thanks
>>> 
>>> Duncan Johnston-Watt
>>> CEO | Cloudsoft Corporation
>>> 
>>> Twitter | @duncanjw
>>> Mobile | +44 777 190 2653
>>> Skype | duncan_johnstonwatt
>>> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
>>> 
>>> On 17 November 2016 at 06:09, Aled Sage  wrote:
>>> 
 +1, sounds great - thanks Andrea!
 
 There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
 that we want, such as an OutOfMemoryError deploying to Softlayer [1].
 
 It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
 release.
 
 In the meantime, we should still get our own house in order by doing the
 first of the steps below (i.e. dealing with open PRs; ensuring no-one
>>> has
 any imminent important contributions to make for 0.10.0, etc).
 
 Aled
 
 [1] https://issues.apache.org/jira/browse/BROOKLYN-364
 
 
 
 On 17/11/2016 11:37, Alex Heneveld wrote:
 
> That would be a great solution Andrea!
> 
> Best
> Alex
> 
> On 17 Nov 2016 08:18, "Andrea Turli" 
> wrote:
> 
> I'm happy to volunteer for releasing an official jclouds 1.9.3 which
>>> may
>> be
>> the half-house solution here.
>> 
>> wdyt?
>> 
>> Andrea
>> 
>> On 17 November 2016 at 08:25, Svetoslav Neykov <
>> svetoslav.ney...@cloudsoftcorp.com> wrote:
>> 
>> This is going to be the first release that actually works in Karaf.
>>> The
>>> docs are still assuming classic though so I suggest we keep
>>> recommending
>>> the classic distribution for 0.10.0.
>>> For next release let's plan on updating the docs and switching the
>>> recommended distribution to the Karaf based one.
>>> 
>>> Svet.
>>> 
>>> 
>>> On 16.11.2016 г., at 13:22, Aled Sage  wrote:
 
 Hi all,
 
 It's far past time that we did a Brooklyn 0.10.0 release! I suggest
>>> we
 
>>> aim for that soon.
>>> 
 To that end, I suggest the following steps:
 
 * Deal with open PRs:
 o People shout out about any PRs you think are very important
>>> to
   be merged, before that release.
 o Review open PRs
   (for any that won't get merged into 0.10.0, clearly mark
>>> them as
   such and say why).
 * Any 

Re: Call for release: Brooklyn 0.10.0

[Andrea Turli]

Hi

jclouds 1.9.3 is officially out -- see
http://markmail.org/thread/qlapnppmfbilje7p for more details



FYI @bostko already created this PR to bump jclouds version
https://github.com/apache/brooklyn-server/pull/457

I've generated the dependency:list from tag rel/jclouds-1.9.2 and
rel/jclouds-1.9.3 from jclouds/jclouds repos (see
https://gist.github.com/andreaturli/b7c178519ab4d029d562643426a2738d and
https://gist.github.com/andreaturli/8d54e4340ef0a4c650022396b4b54b89) and
apart from org.apache.jclouds versions I can't see any new version for the
transitive dependencies.



I've also checked the swift vs openstack-swift issue when targeting the
brooklyn persistence to IBM SoftLayer Object Storage: it works fine with
jclouds 1.9.3 and jclouds 2.0.0 so this shouldn't be an issue for the
release. (see https://github.com/jclouds/jclouds-examples/pull/90)

HTH,
Andrea

On 18 November 2016 at 12:19, Andrea Turli 
wrote:

> Hi there,
>
> I've released the Apache jclouds 1.9.3-rc1 (see [1] and [2] for more
> details)
>
> Please download, test and vote if you can!
>
> Andrea
>
> [1]: https://lists.apache.org/thread.html/42f3a91008890939cf344f35320f86
> bcc48f814119655d7347c9bcca@%3Cdev.jclouds.apache.org%3E
> [2]: https://lists.apache.org/thread.html/94981b8f456785ffea640af3be9207
> 103bb4b7ee2f6d5bb783e98c2c@%3Cdev.jclouds.apache.org%3E
>
> On 17 November 2016 at 19:01, Duncan Johnston Watt  cloudsoftcorp.com> wrote:
>
>> +1 Andrea thanks
>>
>> Duncan Johnston-Watt
>> CEO | Cloudsoft Corporation
>>
>> Twitter | @duncanjw
>> Mobile | +44 777 190 2653
>> Skype | duncan_johnstonwatt
>> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
>>
>> On 17 November 2016 at 06:09, Aled Sage  wrote:
>>
>> > +1, sounds great - thanks Andrea!
>> >
>> > There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
>> > that we want, such as an OutOfMemoryError deploying to Softlayer [1].
>> >
>> > It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
>> > release.
>> >
>> > In the meantime, we should still get our own house in order by doing the
>> > first of the steps below (i.e. dealing with open PRs; ensuring no-one
>> has
>> > any imminent important contributions to make for 0.10.0, etc).
>> >
>> > Aled
>> >
>> > [1] https://issues.apache.org/jira/browse/BROOKLYN-364
>> >
>> >
>> >
>> > On 17/11/2016 11:37, Alex Heneveld wrote:
>> >
>> >> That would be a great solution Andrea!
>> >>
>> >> Best
>> >> Alex
>> >>
>> >> On 17 Nov 2016 08:18, "Andrea Turli" 
>> >> wrote:
>> >>
>> >> I'm happy to volunteer for releasing an official jclouds 1.9.3 which
>> may
>> >>> be
>> >>> the half-house solution here.
>> >>>
>> >>> wdyt?
>> >>>
>> >>> Andrea
>> >>>
>> >>> On 17 November 2016 at 08:25, Svetoslav Neykov <
>> >>> svetoslav.ney...@cloudsoftcorp.com> wrote:
>> >>>
>> >>> This is going to be the first release that actually works in Karaf.
>> The
>>  docs are still assuming classic though so I suggest we keep
>> recommending
>>  the classic distribution for 0.10.0.
>>  For next release let's plan on updating the docs and switching the
>>  recommended distribution to the Karaf based one.
>> 
>>  Svet.
>> 
>> 
>>  On 16.11.2016 г., at 13:22, Aled Sage  wrote:
>> >
>> > Hi all,
>> >
>> > It's far past time that we did a Brooklyn 0.10.0 release! I suggest
>> we
>> >
>>  aim for that soon.
>> 
>> > To that end, I suggest the following steps:
>> >
>> > * Deal with open PRs:
>> >  o People shout out about any PRs you think are very important
>> to
>> >be merged, before that release.
>> >  o Review open PRs
>> >(for any that won't get merged into 0.10.0, clearly mark
>> them as
>> >such and say why).
>> > * Any pending/remaining work:
>> >  o Give people until Friday evening (uk time) to submit any
>> other
>> >very important PRs that are being working on.
>> >  o People shout out about any known issues that they see as
>> >blockers for a release.
>> > * Do some initial testing, using master (before Friday).
>> > * Aim to produce a first release candidate on Friday evening (uk
>> time).
>> > * Do the usual QA/fix cycle until the release is ready.
>> > * Write release notes, etc.
>> >
>> > Of the first steps, reviewing the PRs is a big piece of work! If you
>> >
>>  have time to help, then please lend a hand by reviewing and/or
>> testing
>> 
>> >>> the
>> >>>
>>  PRs, and commenting on them.
>> 
>> > I don't think we should try to squeeze lots of additional PRs into
>> >
>>  0.10.0 - there is already a huge amount in there compared to 0.9.0!
>> 
>> > Richard, are our release process docs up-to-date at [1]?
>> >
>> > Aled
>> >
>> > 

Re: Call for release: Brooklyn 0.10.0

[Andrea Turli]

Hi there,

I've released the Apache jclouds 1.9.3-rc1 (see [1] and [2] for more
details)

Please download, test and vote if you can!

Andrea

[1]:
https://lists.apache.org/thread.html/42f3a91008890939cf344f35320f86bcc48f814119655d7347c9bcca@%3Cdev.jclouds.apache.org%3E
[2]:
https://lists.apache.org/thread.html/94981b8f456785ffea640af3be9207103bb4b7ee2f6d5bb783e98c2c@%3Cdev.jclouds.apache.org%3E

On 17 November 2016 at 19:01, Duncan Johnston Watt <
duncan.johnstonw...@cloudsoftcorp.com> wrote:

> +1 Andrea thanks
>
> Duncan Johnston-Watt
> CEO | Cloudsoft Corporation
>
> Twitter | @duncanjw
> Mobile | +44 777 190 2653
> Skype | duncan_johnstonwatt
> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
>
> On 17 November 2016 at 06:09, Aled Sage  wrote:
>
> > +1, sounds great - thanks Andrea!
> >
> > There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
> > that we want, such as an OutOfMemoryError deploying to Softlayer [1].
> >
> > It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
> > release.
> >
> > In the meantime, we should still get our own house in order by doing the
> > first of the steps below (i.e. dealing with open PRs; ensuring no-one has
> > any imminent important contributions to make for 0.10.0, etc).
> >
> > Aled
> >
> > [1] https://issues.apache.org/jira/browse/BROOKLYN-364
> >
> >
> >
> > On 17/11/2016 11:37, Alex Heneveld wrote:
> >
> >> That would be a great solution Andrea!
> >>
> >> Best
> >> Alex
> >>
> >> On 17 Nov 2016 08:18, "Andrea Turli" 
> >> wrote:
> >>
> >> I'm happy to volunteer for releasing an official jclouds 1.9.3 which may
> >>> be
> >>> the half-house solution here.
> >>>
> >>> wdyt?
> >>>
> >>> Andrea
> >>>
> >>> On 17 November 2016 at 08:25, Svetoslav Neykov <
> >>> svetoslav.ney...@cloudsoftcorp.com> wrote:
> >>>
> >>> This is going to be the first release that actually works in Karaf. The
>  docs are still assuming classic though so I suggest we keep
> recommending
>  the classic distribution for 0.10.0.
>  For next release let's plan on updating the docs and switching the
>  recommended distribution to the Karaf based one.
> 
>  Svet.
> 
> 
>  On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> >
> > Hi all,
> >
> > It's far past time that we did a Brooklyn 0.10.0 release! I suggest
> we
> >
>  aim for that soon.
> 
> > To that end, I suggest the following steps:
> >
> > * Deal with open PRs:
> >  o People shout out about any PRs you think are very important to
> >be merged, before that release.
> >  o Review open PRs
> >(for any that won't get merged into 0.10.0, clearly mark them
> as
> >such and say why).
> > * Any pending/remaining work:
> >  o Give people until Friday evening (uk time) to submit any other
> >very important PRs that are being working on.
> >  o People shout out about any known issues that they see as
> >blockers for a release.
> > * Do some initial testing, using master (before Friday).
> > * Aim to produce a first release candidate on Friday evening (uk
> time).
> > * Do the usual QA/fix cycle until the release is ready.
> > * Write release notes, etc.
> >
> > Of the first steps, reviewing the PRs is a big piece of work! If you
> >
>  have time to help, then please lend a hand by reviewing and/or testing
> 
> >>> the
> >>>
>  PRs, and commenting on them.
> 
> > I don't think we should try to squeeze lots of additional PRs into
> >
>  0.10.0 - there is already a huge amount in there compared to 0.9.0!
> 
> > Richard, are our release process docs up-to-date at [1]?
> >
> > Aled
> >
> > [1] http://brooklyn.apache.org/developers/committers/release-
> >
>  process/index.html
> 
> >
> >
> 
> >
>

Re: Call for release: Brooklyn 0.10.0

[Duncan Johnston Watt]

+1 Andrea thanks

Duncan Johnston-Watt
CEO | Cloudsoft Corporation

Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt

On 17 November 2016 at 06:09, Aled Sage  wrote:

> +1, sounds great - thanks Andrea!
>
> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
> that we want, such as an OutOfMemoryError deploying to Softlayer [1].
>
> It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
> release.
>
> In the meantime, we should still get our own house in order by doing the
> first of the steps below (i.e. dealing with open PRs; ensuring no-one has
> any imminent important contributions to make for 0.10.0, etc).
>
> Aled
>
> [1] https://issues.apache.org/jira/browse/BROOKLYN-364
>
>
>
> On 17/11/2016 11:37, Alex Heneveld wrote:
>
>> That would be a great solution Andrea!
>>
>> Best
>> Alex
>>
>> On 17 Nov 2016 08:18, "Andrea Turli" 
>> wrote:
>>
>> I'm happy to volunteer for releasing an official jclouds 1.9.3 which may
>>> be
>>> the half-house solution here.
>>>
>>> wdyt?
>>>
>>> Andrea
>>>
>>> On 17 November 2016 at 08:25, Svetoslav Neykov <
>>> svetoslav.ney...@cloudsoftcorp.com> wrote:
>>>
>>> This is going to be the first release that actually works in Karaf. The
 docs are still assuming classic though so I suggest we keep recommending
 the classic distribution for 0.10.0.
 For next release let's plan on updating the docs and switching the
 recommended distribution to the Karaf based one.

 Svet.


 On 16.11.2016 г., at 13:22, Aled Sage  wrote:
>
> Hi all,
>
> It's far past time that we did a Brooklyn 0.10.0 release! I suggest we
>
 aim for that soon.

> To that end, I suggest the following steps:
>
> * Deal with open PRs:
>  o People shout out about any PRs you think are very important to
>be merged, before that release.
>  o Review open PRs
>(for any that won't get merged into 0.10.0, clearly mark them as
>such and say why).
> * Any pending/remaining work:
>  o Give people until Friday evening (uk time) to submit any other
>very important PRs that are being working on.
>  o People shout out about any known issues that they see as
>blockers for a release.
> * Do some initial testing, using master (before Friday).
> * Aim to produce a first release candidate on Friday evening (uk time).
> * Do the usual QA/fix cycle until the release is ready.
> * Write release notes, etc.
>
> Of the first steps, reviewing the PRs is a big piece of work! If you
>
 have time to help, then please lend a hand by reviewing and/or testing

>>> the
>>>
 PRs, and commenting on them.

> I don't think we should try to squeeze lots of additional PRs into
>
 0.10.0 - there is already a huge amount in there compared to 0.9.0!

> Richard, are our release process docs up-to-date at [1]?
>
> Aled
>
> [1] http://brooklyn.apache.org/developers/committers/release-
>
 process/index.html

>
>

>

Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

Good point about the homebrew package John. Thanks.

Svet.


> On 17.11.2016 г., at 17:53, John McCabe  wrote:
> 
> If there's a cli bump feel free to ping me about the homebrew release
> process if necessary (it's pretty straight forward).
> /John
> 
> On Thu, 17 Nov 2016, 15:19 Svetoslav Neykov, <
> svetoslav.ney...@cloudsoftcorp.com> wrote:
> 
>> Nobody else stepped up so I guess that's me. I'll give it a go.
>> 
>> Thanks.
>> Svet.
>> 
>> 
>>> On 17.11.2016 г., at 15:40, Richard Downer  wrote:
>>> 
>>> The release-manager-to-be could also start running the release script[1]
>> a
>>> few times in dry run mode to catch any early issues.
>>> 
>>> [1]
>>> 
>> https://github.com/apache/brooklyn-dist/blob/master/release/make-release-artifacts.sh
>>> 
>>> 
>>> On 17 November 2016 at 13:09, Aled Sage  wrote:
>>> 
 +1, sounds great - thanks Andrea!
 
 There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
 that we want, such as an OutOfMemoryError deploying to Softlayer [1].
 
 It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
 release.
 
 In the meantime, we should still get our own house in order by doing the
 first of the steps below (i.e. dealing with open PRs; ensuring no-one
>> has
 any imminent important contributions to make for 0.10.0, etc).
 
 Aled
 
 [1] https://issues.apache.org/jira/browse/BROOKLYN-364
 
 
 
 On 17/11/2016 11:37, Alex Heneveld wrote:
 
> That would be a great solution Andrea!
> 
> Best
> Alex
> 
> On 17 Nov 2016 08:18, "Andrea Turli" 
> wrote:
> 
> I'm happy to volunteer for releasing an official jclouds 1.9.3 which
>> may
>> be
>> the half-house solution here.
>> 
>> wdyt?
>> 
>> Andrea
>> 
>> On 17 November 2016 at 08:25, Svetoslav Neykov <
>> svetoslav.ney...@cloudsoftcorp.com> wrote:
>> 
>> This is going to be the first release that actually works in Karaf.
>> The
>>> docs are still assuming classic though so I suggest we keep
>> recommending
>>> the classic distribution for 0.10.0.
>>> For next release let's plan on updating the docs and switching the
>>> recommended distribution to the Karaf based one.
>>> 
>>> Svet.
>>> 
>>> 
>>> On 16.11.2016 г., at 13:22, Aled Sage  wrote:
 
 Hi all,
 
 It's far past time that we did a Brooklyn 0.10.0 release! I suggest
>> we
 
>>> aim for that soon.
>>> 
 To that end, I suggest the following steps:
 
 * Deal with open PRs:
o People shout out about any PRs you think are very important to
  be merged, before that release.
o Review open PRs
  (for any that won't get merged into 0.10.0, clearly mark them
>> as
  such and say why).
 * Any pending/remaining work:
o Give people until Friday evening (uk time) to submit any other
  very important PRs that are being working on.
o People shout out about any known issues that they see as
  blockers for a release.
 * Do some initial testing, using master (before Friday).
 * Aim to produce a first release candidate on Friday evening (uk
>> time).
 * Do the usual QA/fix cycle until the release is ready.
 * Write release notes, etc.
 
 Of the first steps, reviewing the PRs is a big piece of work! If you
 
>>> have time to help, then please lend a hand by reviewing and/or
>> testing
>>> 
>> the
>> 
>>> PRs, and commenting on them.
>>> 
 I don't think we should try to squeeze lots of additional PRs into
 
>>> 0.10.0 - there is already a huge amount in there compared to 0.9.0!
>>> 
 Richard, are our release process docs up-to-date at [1]?
 
 Aled
 
 [1] http://brooklyn.apache.org/developers/committers/release-
 
>>> process/index.html
>>> 
 
 
>>> 
 
>> 
>> 

Re: Call for release: Brooklyn 0.10.0

[John McCabe]

If there's a cli bump feel free to ping me about the homebrew release
process if necessary (it's pretty straight forward).
/John

On Thu, 17 Nov 2016, 15:19 Svetoslav Neykov, <
svetoslav.ney...@cloudsoftcorp.com> wrote:

> Nobody else stepped up so I guess that's me. I'll give it a go.
>
> Thanks.
> Svet.
>
>
> > On 17.11.2016 г., at 15:40, Richard Downer  wrote:
> >
> > The release-manager-to-be could also start running the release script[1]
> a
> > few times in dry run mode to catch any early issues.
> >
> > [1]
> >
> https://github.com/apache/brooklyn-dist/blob/master/release/make-release-artifacts.sh
> >
> >
> > On 17 November 2016 at 13:09, Aled Sage  wrote:
> >
> >> +1, sounds great - thanks Andrea!
> >>
> >> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
> >> that we want, such as an OutOfMemoryError deploying to Softlayer [1].
> >>
> >> It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
> >> release.
> >>
> >> In the meantime, we should still get our own house in order by doing the
> >> first of the steps below (i.e. dealing with open PRs; ensuring no-one
> has
> >> any imminent important contributions to make for 0.10.0, etc).
> >>
> >> Aled
> >>
> >> [1] https://issues.apache.org/jira/browse/BROOKLYN-364
> >>
> >>
> >>
> >> On 17/11/2016 11:37, Alex Heneveld wrote:
> >>
> >>> That would be a great solution Andrea!
> >>>
> >>> Best
> >>> Alex
> >>>
> >>> On 17 Nov 2016 08:18, "Andrea Turli" 
> >>> wrote:
> >>>
> >>> I'm happy to volunteer for releasing an official jclouds 1.9.3 which
> may
>  be
>  the half-house solution here.
> 
>  wdyt?
> 
>  Andrea
> 
>  On 17 November 2016 at 08:25, Svetoslav Neykov <
>  svetoslav.ney...@cloudsoftcorp.com> wrote:
> 
>  This is going to be the first release that actually works in Karaf.
> The
> > docs are still assuming classic though so I suggest we keep
> recommending
> > the classic distribution for 0.10.0.
> > For next release let's plan on updating the docs and switching the
> > recommended distribution to the Karaf based one.
> >
> > Svet.
> >
> >
> > On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> >>
> >> Hi all,
> >>
> >> It's far past time that we did a Brooklyn 0.10.0 release! I suggest
> we
> >>
> > aim for that soon.
> >
> >> To that end, I suggest the following steps:
> >>
> >> * Deal with open PRs:
> >> o People shout out about any PRs you think are very important to
> >>   be merged, before that release.
> >> o Review open PRs
> >>   (for any that won't get merged into 0.10.0, clearly mark them
> as
> >>   such and say why).
> >> * Any pending/remaining work:
> >> o Give people until Friday evening (uk time) to submit any other
> >>   very important PRs that are being working on.
> >> o People shout out about any known issues that they see as
> >>   blockers for a release.
> >> * Do some initial testing, using master (before Friday).
> >> * Aim to produce a first release candidate on Friday evening (uk
> time).
> >> * Do the usual QA/fix cycle until the release is ready.
> >> * Write release notes, etc.
> >>
> >> Of the first steps, reviewing the PRs is a big piece of work! If you
> >>
> > have time to help, then please lend a hand by reviewing and/or
> testing
> >
>  the
> 
> > PRs, and commenting on them.
> >
> >> I don't think we should try to squeeze lots of additional PRs into
> >>
> > 0.10.0 - there is already a huge amount in there compared to 0.9.0!
> >
> >> Richard, are our release process docs up-to-date at [1]?
> >>
> >> Aled
> >>
> >> [1] http://brooklyn.apache.org/developers/committers/release-
> >>
> > process/index.html
> >
> >>
> >>
> >
> >>
>
>

Re: Call for release: Brooklyn 0.10.0

[Aled Sage]

+1, sounds great - thanks Andrea!

There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0) 
that we want, such as an OutOfMemoryError deploying to Softlayer [1].


It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3 
release.


In the meantime, we should still get our own house in order by doing the 
first of the steps below (i.e. dealing with open PRs; ensuring no-one 
has any imminent important contributions to make for 0.10.0, etc).


Aled

[1] https://issues.apache.org/jira/browse/BROOKLYN-364


On 17/11/2016 11:37, Alex Heneveld wrote:

That would be a great solution Andrea!

Best
Alex

On 17 Nov 2016 08:18, "Andrea Turli"  wrote:


I'm happy to volunteer for releasing an official jclouds 1.9.3 which may be
the half-house solution here.

wdyt?

Andrea

On 17 November 2016 at 08:25, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:


This is going to be the first release that actually works in Karaf. The
docs are still assuming classic though so I suggest we keep recommending
the classic distribution for 0.10.0.
For next release let's plan on updating the docs and switching the
recommended distribution to the Karaf based one.

Svet.



On 16.11.2016 г., at 13:22, Aled Sage  wrote:

Hi all,

It's far past time that we did a Brooklyn 0.10.0 release! I suggest we

aim for that soon.

To that end, I suggest the following steps:

* Deal with open PRs:
 o People shout out about any PRs you think are very important to
   be merged, before that release.
 o Review open PRs
   (for any that won't get merged into 0.10.0, clearly mark them as
   such and say why).
* Any pending/remaining work:
 o Give people until Friday evening (uk time) to submit any other
   very important PRs that are being working on.
 o People shout out about any known issues that they see as
   blockers for a release.
* Do some initial testing, using master (before Friday).
* Aim to produce a first release candidate on Friday evening (uk time).
* Do the usual QA/fix cycle until the release is ready.
* Write release notes, etc.

Of the first steps, reviewing the PRs is a big piece of work! If you

have time to help, then please lend a hand by reviewing and/or testing

the

PRs, and commenting on them.

I don't think we should try to squeeze lots of additional PRs into

0.10.0 - there is already a huge amount in there compared to 0.9.0!

Richard, are our release process docs up-to-date at [1]?

Aled

[1] http://brooklyn.apache.org/developers/committers/release-

process/index.html

Re: Call for release: Brooklyn 0.10.0

[Andrea Turli]

I'm happy to volunteer for releasing an official jclouds 1.9.3 which may be
the half-house solution here.

wdyt?

Andrea

On 17 November 2016 at 08:25, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

> This is going to be the first release that actually works in Karaf. The
> docs are still assuming classic though so I suggest we keep recommending
> the classic distribution for 0.10.0.
> For next release let's plan on updating the docs and switching the
> recommended distribution to the Karaf based one.
>
> Svet.
>
>
> > On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> >
> > Hi all,
> >
> > It's far past time that we did a Brooklyn 0.10.0 release! I suggest we
> aim for that soon.
> >
> > To that end, I suggest the following steps:
> >
> > * Deal with open PRs:
> > o People shout out about any PRs you think are very important to
> >   be merged, before that release.
> > o Review open PRs
> >   (for any that won't get merged into 0.10.0, clearly mark them as
> >   such and say why).
> > * Any pending/remaining work:
> > o Give people until Friday evening (uk time) to submit any other
> >   very important PRs that are being working on.
> > o People shout out about any known issues that they see as
> >   blockers for a release.
> > * Do some initial testing, using master (before Friday).
> > * Aim to produce a first release candidate on Friday evening (uk time).
> > * Do the usual QA/fix cycle until the release is ready.
> > * Write release notes, etc.
> >
> > Of the first steps, reviewing the PRs is a big piece of work! If you
> have time to help, then please lend a hand by reviewing and/or testing the
> PRs, and commenting on them.
> >
> > I don't think we should try to squeeze lots of additional PRs into
> 0.10.0 - there is already a huge amount in there compared to 0.9.0!
> >
> > Richard, are our release process docs up-to-date at [1]?
> >
> > Aled
> >
> > [1] http://brooklyn.apache.org/developers/committers/release-
> process/index.html
> >
> >
>
>

Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

This is going to be the first release that actually works in Karaf. The docs 
are still assuming classic though so I suggest we keep recommending the classic 
distribution for 0.10.0.
For next release let's plan on updating the docs and switching the recommended 
distribution to the Karaf based one.

Svet.


> On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> 
> Hi all,
> 
> It's far past time that we did a Brooklyn 0.10.0 release! I suggest we aim 
> for that soon.
> 
> To that end, I suggest the following steps:
> 
> * Deal with open PRs:
> o People shout out about any PRs you think are very important to
>   be merged, before that release.
> o Review open PRs
>   (for any that won't get merged into 0.10.0, clearly mark them as
>   such and say why).
> * Any pending/remaining work:
> o Give people until Friday evening (uk time) to submit any other
>   very important PRs that are being working on.
> o People shout out about any known issues that they see as
>   blockers for a release.
> * Do some initial testing, using master (before Friday).
> * Aim to produce a first release candidate on Friday evening (uk time).
> * Do the usual QA/fix cycle until the release is ready.
> * Write release notes, etc.
> 
> Of the first steps, reviewing the PRs is a big piece of work! If you have 
> time to help, then please lend a hand by reviewing and/or testing the PRs, 
> and commenting on them.
> 
> I don't think we should try to squeeze lots of additional PRs into 0.10.0 - 
> there is already a huge amount in there compared to 0.9.0!
> 
> Richard, are our release process docs up-to-date at [1]?
> 
> Aled
> 
> [1] 
> http://brooklyn.apache.org/developers/committers/release-process/index.html
> 
> 

Re: Call for release: Brooklyn 0.10.0

[Alex Heneveld]

i find swift too slow as a persistence endpoint in any case; it doesn't 
seem to be designed for the high-transaction rate we do. would losing 
swift hurt anyone?


what are the other 2.0.0 changes/risks?

the reason i push for this is that i've several times hit problems with 
brooklyn using jclouds 192 that we fixed in jclouds in the *spring*.


--a


On 16/11/2016 09:32, Aled Sage wrote:

Hi all,

I favour towards a 0.11.0 for jclouds 2.0.0 soon, with 0.10.0 
depending on jclouds 1.9.2.


That allows users to have a stable release if they want to keep using 
1.9.2 (e.g. if things break in 2.0.0, or they want to update more 
leisurely), but other users can get 2.0.0 once we've had a little 
longer to test with that.


For example, jclouds "swift" is deleted in 2.0.0, replaced with 
"openstack-swift". Unfortunately SoftLayer's object store uses an 
older version of swift that is not compatible with this, so I believe 
does not work with openstack-swift [1]. Upgrading to 2.0.0 would 
therefore break SoftLayer's object store as a persistence endpoint.


Aled

[1] https://issues.apache.org/jira/browse/BROOKLYN-359


On 16/11/2016 15:44, Alex Heneveld wrote:


There have been a lot of improvements to jclouds since their 1.9.2 
release.  Unless there are big issues with using 2.0.0 that would get 
my vote.


Best
Alex


On 16/11/2016 07:26, Andrea Turli wrote:

+1

Svet,

FYI I'm working on #409 and #415 now that jclouds 2.0 is official 
released.


Andrea

On 16 November 2016 at 12:33, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

Is including jclouds 2.0 too big of a change to consider, what do 
people

think?
If that's considered too risky then I suggest following with a 
0.11.0 not

too long after, including jclouds 2.0.
There's already work to get it running with Brooklyn at
https://github.com/apache/brooklyn-server/pull/415 <
https://github.com/apache/brooklyn-server/pull/415> and
https://github.com/apache/brooklyn-server/pull/409 <
https://github.com/apache/brooklyn-server/pull/409>.

Svet.



On 16.11.2016 г., at 13:22, Aled Sage  wrote:

Hi all,

It's far past time that we did a Brooklyn 0.10.0 release! I 
suggest we

aim for that soon.

To that end, I suggest the following steps:

* Deal with open PRs:
 o People shout out about any PRs you think are very important to
   be merged, before that release.
 o Review open PRs
   (for any that won't get merged into 0.10.0, clearly mark 
them as

   such and say why).
* Any pending/remaining work:
 o Give people until Friday evening (uk time) to submit any other
   very important PRs that are being working on.
 o People shout out about any known issues that they see as
   blockers for a release.
* Do some initial testing, using master (before Friday).
* Aim to produce a first release candidate on Friday evening (uk 
time).

* Do the usual QA/fix cycle until the release is ready.
* Write release notes, etc.

Of the first steps, reviewing the PRs is a big piece of work! If you
have time to help, then please lend a hand by reviewing and/or 
testing the

PRs, and commenting on them.

I don't think we should try to squeeze lots of additional PRs into

0.10.0 - there is already a huge amount in there compared to 0.9.0!

Richard, are our release process docs up-to-date at [1]?

Aled

[1] http://brooklyn.apache.org/developers/committers/release-

process/index.html

Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

> I am happy to do the release again this time, but it would probably be wise
> for somebody else to do it this time (with me providing whatever support is
> needed - pairing etc.)

I'd be happy to do the release with your help Richard.

Svet.


> On 16.11.2016 г., at 16:43, Richard Downer  wrote:
> 
> Hi all,
> 
> On 16 November 2016 at 11:22, Aled Sage  wrote:
> 
>> Hi all,
>> 
>> It's far past time that we did a Brooklyn 0.10.0 release! I suggest we aim
>> for that soon.
>> 
> 
> Definitely agree - our last release was in April, so about seven months
> ago. We certainly wouldn't want to wait any longer. It's not a ridiculous
> length of time, but it "feels" like Brooklyn has moved on a lot during that
> time, so there will be a lot in a new release.
> 
> 
>> Richard, are our release process docs up-to-date at [1]?
>> [1] http://brooklyn.apache.org/developers/committers/
>> release-process/index.html
>> 
> 
> They are up-to-date on source control, but the website hasn't been
> republished. (Attention committers: if you merge a PR that changes the
> website, please also update the website!)
> 
> However they have only been used once since graduation, so there are
> probably still areas for improvement. We'd also need to consider if the
> last 6-7 months have caused a need for the release process to change (e.g.
> adding `.deb` artifacts).
> 
> I am happy to do the release again this time, but it would probably be wise
> for somebody else to do it this time (with me providing whatever support is
> needed - pairing etc.)
> 
> 
> On 16 November 2016 at 11:33, Svetoslav Neykov  cloudsoftcorp.com> wrote:
> 
>> Is including jclouds 2.0 too big of a change to consider, what do people
>> think?
>> If that's considered too risky then I suggest following with a 0.11.0 not
>> too long after, including jclouds 2.0.
> 
> 
> Changing the major version of any dependency sounds like a high risk
> change, but I am not involved closely in jclouds so I don't have an opinion
> on this change.
> 
> However I do like the idea of a 0.11.0 following soon after - if the 0.10.0
> sorts out any remaining gremlins in the release script and process, then a
> 0.11.0 release soon after would be a good test of a faster release cadence
> - but release cadence is a subject for a different thread :-)
> 
> Richard.

Re: Call for release: Brooklyn 0.10.0

[Aled Sage]

Hi all,

I favour towards a 0.11.0 for jclouds 2.0.0 soon, with 0.10.0 depending 
on jclouds 1.9.2.


That allows users to have a stable release if they want to keep using 
1.9.2 (e.g. if things break in 2.0.0, or they want to update more 
leisurely), but other users can get 2.0.0 once we've had a little longer 
to test with that.


For example, jclouds "swift" is deleted in 2.0.0, replaced with 
"openstack-swift". Unfortunately SoftLayer's object store uses an older 
version of swift that is not compatible with this, so I believe does not 
work with openstack-swift [1]. Upgrading to 2.0.0 would therefore break 
SoftLayer's object store as a persistence endpoint.


Aled

[1] https://issues.apache.org/jira/browse/BROOKLYN-359


On 16/11/2016 15:44, Alex Heneveld wrote:


There have been a lot of improvements to jclouds since their 1.9.2 
release.  Unless there are big issues with using 2.0.0 that would get 
my vote.


Best
Alex


On 16/11/2016 07:26, Andrea Turli wrote:

+1

Svet,

FYI I'm working on #409 and #415 now that jclouds 2.0 is official 
released.


Andrea

On 16 November 2016 at 12:33, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

Is including jclouds 2.0 too big of a change to consider, what do 
people

think?
If that's considered too risky then I suggest following with a 
0.11.0 not

too long after, including jclouds 2.0.
There's already work to get it running with Brooklyn at
https://github.com/apache/brooklyn-server/pull/415 <
https://github.com/apache/brooklyn-server/pull/415> and
https://github.com/apache/brooklyn-server/pull/409 <
https://github.com/apache/brooklyn-server/pull/409>.

Svet.



On 16.11.2016 г., at 13:22, Aled Sage  wrote:

Hi all,

It's far past time that we did a Brooklyn 0.10.0 release! I suggest we

aim for that soon.

To that end, I suggest the following steps:

* Deal with open PRs:
 o People shout out about any PRs you think are very important to
   be merged, before that release.
 o Review open PRs
   (for any that won't get merged into 0.10.0, clearly mark 
them as

   such and say why).
* Any pending/remaining work:
 o Give people until Friday evening (uk time) to submit any other
   very important PRs that are being working on.
 o People shout out about any known issues that they see as
   blockers for a release.
* Do some initial testing, using master (before Friday).
* Aim to produce a first release candidate on Friday evening (uk 
time).

* Do the usual QA/fix cycle until the release is ready.
* Write release notes, etc.

Of the first steps, reviewing the PRs is a big piece of work! If you
have time to help, then please lend a hand by reviewing and/or 
testing the

PRs, and commenting on them.

I don't think we should try to squeeze lots of additional PRs into

0.10.0 - there is already a huge amount in there compared to 0.9.0!

Richard, are our release process docs up-to-date at [1]?

Aled

[1] http://brooklyn.apache.org/developers/committers/release-

process/index.html

Re: Call for release: Brooklyn 0.10.0

[Alex Heneveld]

There have been a lot of improvements to jclouds since their 1.9.2 
release.  Unless there are big issues with using 2.0.0 that would get my 
vote.


Best
Alex


On 16/11/2016 07:26, Andrea Turli wrote:

+1

Svet,

FYI I'm working on #409 and #415 now that jclouds 2.0 is official released.

Andrea

On 16 November 2016 at 12:33, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:


Is including jclouds 2.0 too big of a change to consider, what do people
think?
If that's considered too risky then I suggest following with a 0.11.0 not
too long after, including jclouds 2.0.
There's already work to get it running with Brooklyn at
https://github.com/apache/brooklyn-server/pull/415 <
https://github.com/apache/brooklyn-server/pull/415> and
https://github.com/apache/brooklyn-server/pull/409 <
https://github.com/apache/brooklyn-server/pull/409>.

Svet.



On 16.11.2016 г., at 13:22, Aled Sage  wrote:

Hi all,

It's far past time that we did a Brooklyn 0.10.0 release! I suggest we

aim for that soon.

To that end, I suggest the following steps:

* Deal with open PRs:
 o People shout out about any PRs you think are very important to
   be merged, before that release.
 o Review open PRs
   (for any that won't get merged into 0.10.0, clearly mark them as
   such and say why).
* Any pending/remaining work:
 o Give people until Friday evening (uk time) to submit any other
   very important PRs that are being working on.
 o People shout out about any known issues that they see as
   blockers for a release.
* Do some initial testing, using master (before Friday).
* Aim to produce a first release candidate on Friday evening (uk time).
* Do the usual QA/fix cycle until the release is ready.
* Write release notes, etc.

Of the first steps, reviewing the PRs is a big piece of work! If you

have time to help, then please lend a hand by reviewing and/or testing the
PRs, and commenting on them.

I don't think we should try to squeeze lots of additional PRs into

0.10.0 - there is already a huge amount in there compared to 0.9.0!

Richard, are our release process docs up-to-date at [1]?

Aled

[1] http://brooklyn.apache.org/developers/committers/release-

process/index.html

Re: Call for release: Brooklyn 0.10.0

[Richard Downer]

Hi all,

On 16 November 2016 at 11:22, Aled Sage  wrote:

> Hi all,
>
> It's far past time that we did a Brooklyn 0.10.0 release! I suggest we aim
> for that soon.
>

Definitely agree - our last release was in April, so about seven months
ago. We certainly wouldn't want to wait any longer. It's not a ridiculous
length of time, but it "feels" like Brooklyn has moved on a lot during that
time, so there will be a lot in a new release.


> Richard, are our release process docs up-to-date at [1]?
> [1] http://brooklyn.apache.org/developers/committers/
> release-process/index.html
>

They are up-to-date on source control, but the website hasn't been
republished. (Attention committers: if you merge a PR that changes the
website, please also update the website!)

However they have only been used once since graduation, so there are
probably still areas for improvement. We'd also need to consider if the
last 6-7 months have caused a need for the release process to change (e.g.
adding `.deb` artifacts).

I am happy to do the release again this time, but it would probably be wise
for somebody else to do it this time (with me providing whatever support is
needed - pairing etc.)


On 16 November 2016 at 11:33, Svetoslav Neykov  wrote:

> Is including jclouds 2.0 too big of a change to consider, what do people
> think?
> If that's considered too risky then I suggest following with a 0.11.0 not
> too long after, including jclouds 2.0.


Changing the major version of any dependency sounds like a high risk
change, but I am not involved closely in jclouds so I don't have an opinion
on this change.

However I do like the idea of a 0.11.0 following soon after - if the 0.10.0
sorts out any remaining gremlins in the release script and process, then a
0.11.0 release soon after would be a good test of a faster release cadence
- but release cadence is a subject for a different thread :-)

Richard.

Re: Call for release: Brooklyn 0.10.0

[Andrea Turli]

+1

Svet,

FYI I'm working on #409 and #415 now that jclouds 2.0 is official released.

Andrea

On 16 November 2016 at 12:33, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

> Is including jclouds 2.0 too big of a change to consider, what do people
> think?
> If that's considered too risky then I suggest following with a 0.11.0 not
> too long after, including jclouds 2.0.
> There's already work to get it running with Brooklyn at
> https://github.com/apache/brooklyn-server/pull/415 <
> https://github.com/apache/brooklyn-server/pull/415> and
> https://github.com/apache/brooklyn-server/pull/409 <
> https://github.com/apache/brooklyn-server/pull/409>.
>
> Svet.
>
>
> > On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> >
> > Hi all,
> >
> > It's far past time that we did a Brooklyn 0.10.0 release! I suggest we
> aim for that soon.
> >
> > To that end, I suggest the following steps:
> >
> > * Deal with open PRs:
> > o People shout out about any PRs you think are very important to
> >   be merged, before that release.
> > o Review open PRs
> >   (for any that won't get merged into 0.10.0, clearly mark them as
> >   such and say why).
> > * Any pending/remaining work:
> > o Give people until Friday evening (uk time) to submit any other
> >   very important PRs that are being working on.
> > o People shout out about any known issues that they see as
> >   blockers for a release.
> > * Do some initial testing, using master (before Friday).
> > * Aim to produce a first release candidate on Friday evening (uk time).
> > * Do the usual QA/fix cycle until the release is ready.
> > * Write release notes, etc.
> >
> > Of the first steps, reviewing the PRs is a big piece of work! If you
> have time to help, then please lend a hand by reviewing and/or testing the
> PRs, and commenting on them.
> >
> > I don't think we should try to squeeze lots of additional PRs into
> 0.10.0 - there is already a huge amount in there compared to 0.9.0!
> >
> > Richard, are our release process docs up-to-date at [1]?
> >
> > Aled
> >
> > [1] http://brooklyn.apache.org/developers/committers/release-
> process/index.html
> >
> >
>
>

Re: Call for release: Brooklyn 0.10.0

[Svetoslav Neykov]

Is including jclouds 2.0 too big of a change to consider, what do people think?
If that's considered too risky then I suggest following with a 0.11.0 not too 
long after, including jclouds 2.0.
There's already work to get it running with Brooklyn at 
https://github.com/apache/brooklyn-server/pull/415 
 and 
https://github.com/apache/brooklyn-server/pull/409 
.

Svet.


> On 16.11.2016 г., at 13:22, Aled Sage  wrote:
> 
> Hi all,
> 
> It's far past time that we did a Brooklyn 0.10.0 release! I suggest we aim 
> for that soon.
> 
> To that end, I suggest the following steps:
> 
> * Deal with open PRs:
> o People shout out about any PRs you think are very important to
>   be merged, before that release.
> o Review open PRs
>   (for any that won't get merged into 0.10.0, clearly mark them as
>   such and say why).
> * Any pending/remaining work:
> o Give people until Friday evening (uk time) to submit any other
>   very important PRs that are being working on.
> o People shout out about any known issues that they see as
>   blockers for a release.
> * Do some initial testing, using master (before Friday).
> * Aim to produce a first release candidate on Friday evening (uk time).
> * Do the usual QA/fix cycle until the release is ready.
> * Write release notes, etc.
> 
> Of the first steps, reviewing the PRs is a big piece of work! If you have 
> time to help, then please lend a hand by reviewing and/or testing the PRs, 
> and commenting on them.
> 
> I don't think we should try to squeeze lots of additional PRs into 0.10.0 - 
> there is already a huge amount in there compared to 0.9.0!
> 
> Richard, are our release process docs up-to-date at [1]?
> 
> Aled
> 
> [1] 
> http://brooklyn.apache.org/developers/committers/release-process/index.html
> 
> 

Call for release: Brooklyn 0.10.0

[Aled Sage]

Hi all,

It's far past time that we did a Brooklyn 0.10.0 release! I suggest we 
aim for that soon.


To that end, I suggest the following steps:

 * Deal with open PRs:
 o People shout out about any PRs you think are very important to
   be merged, before that release.
 o Review open PRs
   (for any that won't get merged into 0.10.0, clearly mark them as
   such and say why).
 * Any pending/remaining work:
 o Give people until Friday evening (uk time) to submit any other
   very important PRs that are being working on.
 o People shout out about any known issues that they see as
   blockers for a release.
 * Do some initial testing, using master (before Friday).
 * Aim to produce a first release candidate on Friday evening (uk time).
 * Do the usual QA/fix cycle until the release is ready.
 * Write release notes, etc.

Of the first steps, reviewing the PRs is a big piece of work! If you 
have time to help, then please lend a hand by reviewing and/or testing 
the PRs, and commenting on them.


I don't think we should try to squeeze lots of additional PRs into 
0.10.0 - there is already a huge amount in there compared to 0.9.0!


Richard, are our release process docs up-to-date at [1]?

Aled

[1] 
http://brooklyn.apache.org/developers/committers/release-process/index.html