// Changing subject from "Re: Call for release: Brooklyn 0.10.0" to "[DISCUSS] Release Apache Brooklyn 0.10.0 RC1"
0.10.0 will be the first release to support Karaf. The documentation still covers the classic release so it will be the recommended distribution to use. I suggest that we include the Karaf distribution in the release artifacts so people can experiment with it. For this we need to include a LICENSE file, listing all dependencies and their corresponding licenses. The automation which helps us do this for the classic distribution (thanks Alex for creating it, it's a huge time saver) doesn't work on feature files. Any thoughts on the above? Volunteers to step up and help with extracting the dependencies and their licenses for Karaf dist? Svet. > On 24.11.2016 г., at 17:57, Svetoslav Neykov > <svetoslav.ney...@cloudsoftcorp.com> wrote: > > 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 >> <svetoslav.ney...@cloudsoftcorp.com> 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 <rich...@apache.org> 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 <andrea.tu...@cloudsoftcorp.com> >>>> 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 <andrea.turli@cloudsoftcorp. >>>> 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 <duncan.johnstonwatt@ >>>>>> 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 <aled.s...@gmail.com> 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" <andrea.tu...@cloudsoftcorp.com >>>>> >>>>>>>>> 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 <aled.s...@gmail.com> 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 >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >
