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 <rich...@apache.org> 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 <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 >>>>> >>>>>> >>>>>> >>>>> >>
