You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Andrija Panic <an...@gmail.com> on 2020/01/22 11:22:32 UTC
Re: [PROPOSE] RM for 4.14
Hi all,
I’d like to push back the freeze date for at least a week vs. what's
previously proposed since I’ve been contacted by a few people who have some
PRs they like to get closed off. If of any interest, I’m away 27th-31th
January (but will check emails occasionally).
I'll follow-up here on the freeze date.
Thanks,
Andrija
On Fri, 20 Dec 2019 at 16:30, Andrija Panic <an...@gmail.com> wrote:
> Hi guys
>
> Sven,
> read the original email pls (last part of it) - we will need to fix some
> bugs, test other people fixes as applicable, etc - "usual" day to dev
> stuff.
>
> Gabriel,
>
> thx for the help (in advance! ), let's aim to improve the page during this
> release, I'll surely raise this if/when I see a problem (considering this
> is my first time but I will also have help from other experienced guys as
> already explained).
>
> As for the LTS discussion, I would add that there is an "awful" lot of new
> stuff planned for this releases, making it a more suitable candidate for
> LTS then for non-LTS, if that makes sense.
>
> Anyway, looking forward working with all you guys on this one!
>
> Best,
> Andrija
>
>
>
> On Fri, 20 Dec 2019, 12:24 Sven Vogel, <S....@ewerk.com> wrote:
>
>> @Paul @Gabriel
>>
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>>
>>
>> This seems the link for the release process. I read them. how is it
>> possible to engage in this process? I don’t know. Is it useful. I would
>> come more into and learn it.
>>
>>
>>
>>
>> Von meinem iPhone gesendet
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> EWERK DIGITAL GmbH
>> Brühl 24, D-04109 Leipzig
>> P +49 341 42649 - 99
>> F +49 341 42649 - 98
>> S.Vogel@ewerk.com
>> www.ewerk.com
>>
>> Geschäftsführer:
>> Dr. Erik Wende, Hendrik Schubert, Frank Richter
>> Registergericht: Leipzig HRB 9065
>>
>> Support:
>> +49 341 42649 555
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 20000-1:2011
>>
>> ISAE 3402 Typ II Assessed
>>
>> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
>> https://www.linkedin.com/company/ewerk-group> | Xing<
>> https://www.xing.com/company/ewerk> | Twitter<
>> https://twitter.com/EWERK_Group> | Facebook<
>> https://de-de.facebook.com/EWERK.IT/>
>>
>> Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH auf
>> die EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem Namen:
>> EWERK DIGITAL GmbH, für weitere Informationen klicken Sie hier<
>> https://www.ewerk.com/ewerkdigital>.
>>
>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>
>> Disclaimer Privacy:
>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
>> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
>> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
>> Vielen Dank.
>>
>> The contents of this e-mail (including any attachments) are confidential
>> and may be legally privileged. If you are not the intended recipient of
>> this e-mail, any disclosure, copying, distribution or use of its contents
>> is strictly prohibited, and you should please notify the sender immediately
>> and then delete it (including any attachments) from your system. Thank you.
>>
>> Am 20.12.2019 um 12:01 schrieb Gabriel Beims Bräscher <
>> gabrascher@gmail.com>:
>>
>> Hi Paul, thanks for the clarification.
>> First of all, count with me for any help with the 4.14 release process :-)
>>
>> I have no problem with 4.14 becoming the next LTS, having 2 LTS releases
>> per year sounds good. It is worth to mention that with the past releases
>> holding +200 commits it was quite a challenge to ensure stability. Just
>> raising attention to the fact that we might need to support 2 LTS in
>> parallel for longer than on prior LTS (not a problem for me). Hope that we
>> can keep a nice balance between new features and stability.
>>
>> Additionally, we have some outdated documents regarding the releasing
>> process and it must be reviewed and updated accordingly. This was a
>> problem
>> for me when releasing 4.12.
>> For the future, I would like to see a discussion around the releasing
>> process and the pace for future releases. With such discussion formalized
>> and documented, we can make life easier for RMs and also give a better
>> perspective of the project status and roadmap to users/developers.
>>
>> Kind regards,
>> Gabriel.
>>
>> Em qui., 19 de dez. de 2019 às 19:58, Greg Goodrich <
>> GGoodrich@ippathways.com> escreveu:
>>
>> A minor note that those 4.14 dates should all be 2020, not 2019
>>
>> --
>> Greg Goodrich | IP Pathways
>> Senior Developer
>> 3600 109th Street | Urbandale, IA 50322
>> p. 515.422.9346 | e. ggoodrich@ippathways.com<ma...@ippathways.com>
>>
>> On Dec 19, 2019, at 12:30 PM, Paul Angus <paul.angus@shapeblue.com
>> <mailto:
>> paul.angus@shapeblue.com>> wrote:
>>
>> I can answer that one...
>>
>> The 'plan' was always 2 new LTS branches a year - effectively summer and
>> winter. Remember at the time, some members of the community were going
>> for
>> a release every month. So the idea was - whatever the branch was the
>> current branch at the time that an LTS was due, that branch would get some
>> 'extra treatment' and be supported for a few years rather than a few
>> months.
>>
>> Very importantly, the post x.x.0 LTS releases were to have no new features
>> - just bugfixes. So larger organisations with stricter change control,
>> their own documentation and their own integrations, could stay on a
>> 'supported' branch but still get bug fixes in releases, without having to
>> worry about, test or document new features constantly.
>>
>> (I'll hand-wave over the fact that one person's feature is another
>> person's improvement, is another person's bugfix)
>>
>> Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1 with all
>> critical/blocker/major bugfixes in it (probably as soon as enough people
>> have recovered from a 4.14 release cycle) but it can't have any new
>> features in it.
>>
>> So looking forward, if someone wants a 4.15 release in (say) April, then
>> the 'summer' LTS branch (July/August time) will be 4.16, if not, then the
>> summer LTS release would be 4.15
>>
>> I hope that helps 😊
>>
>>
>> Kind regards
>>
>> Paul.
>>
>>
>> paul.angus@shapeblue.com<ma...@shapeblue.com>
>> www.shapeblue.com<http://www.shapeblue.com>
>> Amadeus House, Floral Street, London WC2E 9DPUK
>> @shapeblue
>>
>>
>>
>>
>> -----Original Message-----
>> From: Gabriel Beims Bräscher <ga...@gmail.com>
>> Sent: 19 December 2019 16:59
>> To: dev <de...@cloudstack.apache.org>
>> Subject: Re: [PROPOSE] RM for 4.14
>>
>> Hello Andrija,
>>
>> That is always good news to have contributors stepping up and getting new
>> releases done. We definitely need a release (either a major or a 4.13.1.0)
>> to keep the project traction. However, I would like to understand why
>> 4.14.0.0 is being considered an LTS release.
>> As far as I know, the next major release was supposed to be a regular
>> (non-LTS) release in the midle of the current LTS and next one LTS. Our
>> current LTS 4.13.0.0 is young and with still has some room for bugfixes.
>>
>> For reference, here follows the Release Calendar, more details at [1].
>> 4.9.2.0, LTS, released at 15 December 2016, EOL 1 July 2018 4.9.3.0, LTS,
>> released at 11 September 2017, EOL 1 July 2018 4.11.0.0, LTS, released at
>> 12 February 2018, EOL July 2019 4.12.0.0, Regular, released at 4 April
>> 2019, N/A 4.13.0.0, LTS, released at 24 September 2019, Current LTS
>> 4.14.0.0, LTS/Regular, planned to 21.Feb 2019+
>>
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>>
>> Regards,
>> Gabriel.
>>
>>
>> Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel <S....@ewerk.com>
>> escreveu:
>>
>> Hi Andrija,
>>
>> How can I help and engage in this process?
>>
>> Cheers
>>
>> Sven
>>
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> EWERK DIGITAL GmbH
>> Brühl 24, D-04109 Leipzig
>> P +49 341 42649 - 99
>> F +49 341 42649 - 98
>> S.Vogel@ewerk.com
>> www.ewerk.com
>>
>> Geschäftsführer:
>> Dr. Erik Wende, Hendrik Schubert, Frank Richter
>> Registergericht: Leipzig HRB 9065
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 20000-1:2011
>>
>> EWERK-Blog | LinkedIn | Xing | Twitter | Facebook
>>
>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>
>> Disclaimer Privacy:
>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht
>> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>> informieren Sie in diesem Fall unverzüglich den Absender und löschen
>> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
>> System.
>> Vielen Dank.
>>
>> The contents of this e-mail (including any attachments) are
>> confidential and may be legally privileged. If you are not the
>> intended recipient of this e-mail, any disclosure, copying,
>> distribution or use of its contents is strictly prohibited, and you
>> should please notify the sender immediately and then delete it (including
>> any attachments) from your system. Thank you.
>> Am 19.12.2019 um 17:05 schrieb Andrija Panic <an...@gmail.com>:
>>
>> Hi All,
>>
>> I’d like to put myself forward as release manager for 4.14. The
>> 4.14 releases will be the next major version LTS release and will be
>> supported for 20 months per the LTS manifesto [2].
>>
>> I'll have support from Rohit/Daan/Paul during the process and anyone
>> else interested is most welcome to join the effort.
>>
>> The proposed timeline (possibly a bit too ambitious) is as follows:
>>
>> ######################################
>> 24.Jan 2019 --> Code freeze
>> 31.Jan-07.Feb 2019 --> Cut first RC
>> 21.Feb 2019+ --> Release
>> ######################################
>>
>> As usual, kindly note the following "behaviour" to be in place
>> (pretty much copy/paste from the related 4.11 email from Rohit):
>>
>> ######################################
>> 1. After the freeze date (expected 24th Jan) until GA release,
>> features will not be allowed and fixes will be only as long as there
>> are blocker issues outstanding. Fixes for other issues will be
>> individually judged on their merit and risk.
>> 2. RM will triage/report critical and blocker bugs for 4.14 and
>> encourage people to get them fixed.
>> 3. RM will create RCs and start voting once blocker bugs are cleared
>> and baseline smoke test results are on par with previous 4.13 smoke
>> test
>> results
>> test results.
>> 4. RM will allocate at least a week for branch stabilization and testing.
>> At the earliest, on 31st January, RM will put 4.14.0.0-rc1 for
>> voting
>> from
>> the 4.14 branch, and master will be open to accepting new features.
>> 5. RM will repeat 2-4 as required. Voting/testing of -rc2, -rc3 and
>> so
>> on,
>> will be created as required
>> 6. Once vote passes - RM will continue with the release procedures [1].
>>
>> I’d like the community (including myself and colleagues) to:
>> - Up to 24th January, community members try to review, test and
>> merge as many fixes as possible, being super-diligent to not
>> de-stabilize the master branch.
>> - Engage with gatekeepers to get your PRs reviewed, tested and
>> merged (currently myself, Rohit, Daan and Paul, others are welcome
>> to engage as well). Do not merge the PRs
>> - A pull request may be reverted where the author(s) are not
>> responding and authors may be asked to re-submit their changes after
>> taking suitable remedies.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu
>> re
>> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> ######################################
>> --
>>
>>
>> Andrija Panić
>>
>>
>>
>>
--
Andrija Panić
Re: [PROPOSE] RM for 4.14
Posted by Andrija Panic <an...@gmail.com>.
Hi all,
4.13.1 and 4.14 are almost cooked - all outstanding PRs merged
(documentation is WIP) and automated tests on branches are running.
I'm looking forward to cutting RC1s early next week - 2 separate voting
threads for 4.13.1.0 and 4.14.0.0 releases - as proposed in another email
thread (all 4.13.1 fixes are forward merged to 4.14 as one would expect)
For the records, last 2-3 weeks were mostly spent on the blocker issues
(90% of that on the snapshot garbage left all over the place - PR 3969) -
and most of it has been fixed.
I have pinged some of you already - if you want to help, kindly check the
documentation PRs
https://github.com/apache/cloudstack-documentation/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.14.0.0
Big thanks to everyone who helped so far with fixing the issues and testing!
Andrija
On Thu, 30 Jan 2020 at 21:39, Andrija Panic <an...@gmail.com> wrote:
> Hi all,
>
> with regards to the freeze date, it seems that we'll have to push it back
> a bit, again.
>
> I have not had time to do much myself (will rejoin the effort starting
> from Monday), but I can see that we have reduced total number of Milestone
> items (for both 4.14 and 4.13.1) by 1/3 (we went from ~60 to ~40) - this
> leaves us with roughly another **2 weeks** to finish off the remaining
> milestone items. Next time I might propose a very "pessimistic" dates,
> instead of overly optimistic (that original dates I proposed seem to be),
> to avoid postponing the release by this amount of time.
>
> I hope that everyone finds this OK - at the end of the day, WHAT we
> release it what's going to be remembered, not WHEN we released it.
> As usual, I will follow up here once we are close to the freeze date.
>
> If anyone has any concerns, please let me know.
>
> Thanks,
> Andrija
>
>
> On Wed, 22 Jan 2020 at 15:18, Boris Stoyanov <bo...@shapeblue.com>
> wrote:
>
>> +1, I'd really love to see some of the PRs with the 4.14 milestone in but
>> I need more time to test them.
>>
>> Bobby.
>>
>> On 22.01.20, 13:22, "Andrija Panic" <an...@gmail.com> wrote:
>>
>> Hi all,
>>
>> I’d like to push back the freeze date for at least a week vs. what's
>> previously proposed since I’ve been contacted by a few people who
>> have some
>> PRs they like to get closed off. If of any interest, I’m away
>> 27th-31th
>> January (but will check emails occasionally).
>>
>> I'll follow-up here on the freeze date.
>>
>> Thanks,
>> Andrija
>>
>>
>>
>> boris.stoyanov@shapeblue.com
>> www.shapeblue.com
>> Amadeus House, Floral Street, London WC2E 9DPUK
>> @shapeblue
>>
>>
>>
>> On Fri, 20 Dec 2019 at 16:30, Andrija Panic <an...@gmail.com>
>> wrote:
>>
>> > Hi guys
>> >
>> > Sven,
>> > read the original email pls (last part of it) - we will need to fix
>> some
>> > bugs, test other people fixes as applicable, etc - "usual" day to
>> dev
>> > stuff.
>> >
>> > Gabriel,
>> >
>> > thx for the help (in advance! ), let's aim to improve the page
>> during this
>> > release, I'll surely raise this if/when I see a problem
>> (considering this
>> > is my first time but I will also have help from other experienced
>> guys as
>> > already explained).
>> >
>> > As for the LTS discussion, I would add that there is an "awful" lot
>> of new
>> > stuff planned for this releases, making it a more suitable
>> candidate for
>> > LTS then for non-LTS, if that makes sense.
>> >
>> > Anyway, looking forward working with all you guys on this one!
>> >
>> > Best,
>> > Andrija
>> >
>> >
>> >
>> > On Fri, 20 Dec 2019, 12:24 Sven Vogel, <S....@ewerk.com> wrote:
>> >
>> >> @Paul @Gabriel
>> >>
>> >>
>> >>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>> >>
>> >>
>> >> This seems the link for the release process. I read them. how is it
>> >> possible to engage in this process? I don’t know. Is it useful. I
>> would
>> >> come more into and learn it.
>> >>
>> >>
>> >>
>> >>
>> >> Von meinem iPhone gesendet
>> >>
>> >>
>> >> __
>> >>
>> >> Sven Vogel
>> >> Teamlead Platform
>> >>
>> >> EWERK DIGITAL GmbH
>> >> Brühl 24, D-04109 Leipzig
>> >> P +49 341 42649 - 99
>> >> F +49 341 42649 - 98
>> >> S.Vogel@ewerk.com
>> >> www.ewerk.com
>> >>
>> >> Geschäftsführer:
>> >> Dr. Erik Wende, Hendrik Schubert, Frank Richter
>> >> Registergericht: Leipzig HRB 9065
>> >>
>> >> Support:
>> >> +49 341 42649 555
>> >>
>> >> Zertifiziert nach:
>> >> ISO/IEC 27001:2013
>> >> DIN EN ISO 9001:2015
>> >> DIN ISO/IEC 20000-1:2011
>> >>
>> >> ISAE 3402 Typ II Assessed
>> >>
>> >> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
>> >> https://www.linkedin.com/company/ewerk-group> | Xing<
>> >> https://www.xing.com/company/ewerk> | Twitter<
>> >> https://twitter.com/EWERK_Group> | Facebook<
>> >> https://de-de.facebook.com/EWERK.IT/>
>> >>
>> >> Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH
>> auf
>> >> die EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter
>> dem Namen:
>> >> EWERK DIGITAL GmbH, für weitere Informationen klicken Sie hier<
>> >> https://www.ewerk.com/ewerkdigital>.
>> >>
>> >> Auskünfte und Angebote per Mail sind freibleibend und
>> unverbindlich.
>> >>
>> >> Disclaimer Privacy:
>> >> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter
>> Dateien)
>> >> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie
>> nicht der
>> >> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> >> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt.
>> Bitte
>> >> informieren Sie in diesem Fall unverzüglich den Absender und
>> löschen Sie
>> >> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
>> System.
>> >> Vielen Dank.
>> >>
>> >> The contents of this e-mail (including any attachments) are
>> confidential
>> >> and may be legally privileged. If you are not the intended
>> recipient of
>> >> this e-mail, any disclosure, copying, distribution or use of its
>> contents
>> >> is strictly prohibited, and you should please notify the sender
>> immediately
>> >> and then delete it (including any attachments) from your system.
>> Thank you.
>> >>
>> >> Am 20.12.2019 um 12:01 schrieb Gabriel Beims Bräscher <
>> >> gabrascher@gmail.com>:
>> >>
>> >> Hi Paul, thanks for the clarification.
>> >> First of all, count with me for any help with the 4.14 release
>> process :-)
>> >>
>> >> I have no problem with 4.14 becoming the next LTS, having 2 LTS
>> releases
>> >> per year sounds good. It is worth to mention that with the past
>> releases
>> >> holding +200 commits it was quite a challenge to ensure stability.
>> Just
>> >> raising attention to the fact that we might need to support 2 LTS
>> in
>> >> parallel for longer than on prior LTS (not a problem for me). Hope
>> that we
>> >> can keep a nice balance between new features and stability.
>> >>
>> >> Additionally, we have some outdated documents regarding the
>> releasing
>> >> process and it must be reviewed and updated accordingly. This was a
>> >> problem
>> >> for me when releasing 4.12.
>> >> For the future, I would like to see a discussion around the
>> releasing
>> >> process and the pace for future releases. With such discussion
>> formalized
>> >> and documented, we can make life easier for RMs and also give a
>> better
>> >> perspective of the project status and roadmap to users/developers.
>> >>
>> >> Kind regards,
>> >> Gabriel.
>> >>
>> >> Em qui., 19 de dez. de 2019 às 19:58, Greg Goodrich <
>> >> GGoodrich@ippathways.com> escreveu:
>> >>
>> >> A minor note that those 4.14 dates should all be 2020, not 2019
>> >>
>> >> --
>> >> Greg Goodrich | IP Pathways
>> >> Senior Developer
>> >> 3600 109th Street | Urbandale, IA 50322
>> >> p. 515.422.9346 | e. ggoodrich@ippathways.com<mailto:
>> jfry@ippathways.com>
>> >>
>> >> On Dec 19, 2019, at 12:30 PM, Paul Angus <paul.angus@shapeblue.com
>> >> <mailto:
>> >> paul.angus@shapeblue.com>> wrote:
>> >>
>> >> I can answer that one...
>> >>
>> >> The 'plan' was always 2 new LTS branches a year - effectively
>> summer and
>> >> winter. Remember at the time, some members of the community were
>> going
>> >> for
>> >> a release every month. So the idea was - whatever the branch was
>> the
>> >> current branch at the time that an LTS was due, that branch would
>> get some
>> >> 'extra treatment' and be supported for a few years rather than a
>> few
>> >> months.
>> >>
>> >> Very importantly, the post x.x.0 LTS releases were to have no new
>> features
>> >> - just bugfixes. So larger organisations with stricter change
>> control,
>> >> their own documentation and their own integrations, could stay on a
>> >> 'supported' branch but still get bug fixes in releases, without
>> having to
>> >> worry about, test or document new features constantly.
>> >>
>> >> (I'll hand-wave over the fact that one person's feature is another
>> >> person's improvement, is another person's bugfix)
>> >>
>> >> Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1
>> with all
>> >> critical/blocker/major bugfixes in it (probably as soon as enough
>> people
>> >> have recovered from a 4.14 release cycle) but it can't have any new
>> >> features in it.
>> >>
>> >> So looking forward, if someone wants a 4.15 release in (say)
>> April, then
>> >> the 'summer' LTS branch (July/August time) will be 4.16, if not,
>> then the
>> >> summer LTS release would be 4.15
>> >>
>> >> I hope that helps 😊
>> >>
>> >>
>> >> Kind regards
>> >>
>> >> Paul.
>> >>
>> >>
>> >> paul.angus@shapeblue.com<ma...@shapeblue.com>
>> >> www.shapeblue.com<http://www.shapeblue.com>
>> >> Amadeus House, Floral Street, London WC2E 9DPUK
>> >> @shapeblue
>> >>
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Gabriel Beims Bräscher <ga...@gmail.com>
>> >> Sent: 19 December 2019 16:59
>> >> To: dev <de...@cloudstack.apache.org>
>> >> Subject: Re: [PROPOSE] RM for 4.14
>> >>
>> >> Hello Andrija,
>> >>
>> >> That is always good news to have contributors stepping up and
>> getting new
>> >> releases done. We definitely need a release (either a major or a
>> 4.13.1.0)
>> >> to keep the project traction. However, I would like to understand
>> why
>> >> 4.14.0.0 is being considered an LTS release.
>> >> As far as I know, the next major release was supposed to be a
>> regular
>> >> (non-LTS) release in the midle of the current LTS and next one
>> LTS. Our
>> >> current LTS 4.13.0.0 is young and with still has some room for
>> bugfixes.
>> >>
>> >> For reference, here follows the Release Calendar, more details at
>> [1].
>> >> 4.9.2.0, LTS, released at 15 December 2016, EOL 1 July 2018
>> 4.9.3.0, LTS,
>> >> released at 11 September 2017, EOL 1 July 2018 4.11.0.0, LTS,
>> released at
>> >> 12 February 2018, EOL July 2019 4.12.0.0, Regular, released at 4
>> April
>> >> 2019, N/A 4.13.0.0, LTS, released at 24 September 2019, Current LTS
>> >> 4.14.0.0, LTS/Regular, planned to 21.Feb 2019+
>> >>
>> >> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> >>
>> >> Regards,
>> >> Gabriel.
>> >>
>> >>
>> >> Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel <
>> S.Vogel@ewerk.com>
>> >> escreveu:
>> >>
>> >> Hi Andrija,
>> >>
>> >> How can I help and engage in this process?
>> >>
>> >> Cheers
>> >>
>> >> Sven
>> >>
>> >>
>> >>
>> >> __
>> >>
>> >> Sven Vogel
>> >> Teamlead Platform
>> >>
>> >> EWERK DIGITAL GmbH
>> >> Brühl 24, D-04109 Leipzig
>> >> P +49 341 42649 - 99
>> >> F +49 341 42649 - 98
>> >> S.Vogel@ewerk.com
>> >> www.ewerk.com
>> >>
>> >> Geschäftsführer:
>> >> Dr. Erik Wende, Hendrik Schubert, Frank Richter
>> >> Registergericht: Leipzig HRB 9065
>> >>
>> >> Zertifiziert nach:
>> >> ISO/IEC 27001:2013
>> >> DIN EN ISO 9001:2015
>> >> DIN ISO/IEC 20000-1:2011
>> >>
>> >> EWERK-Blog | LinkedIn | Xing | Twitter | Facebook
>> >>
>> >> Auskünfte und Angebote per Mail sind freibleibend und
>> unverbindlich.
>> >>
>> >> Disclaimer Privacy:
>> >> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter
>> Dateien)
>> >> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie
>> nicht
>> >> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche
>> Offenlegung,
>> >> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt.
>> Bitte
>> >> informieren Sie in diesem Fall unverzüglich den Absender und
>> löschen
>> >> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von
>> Ihrem
>> >> System.
>> >> Vielen Dank.
>> >>
>> >> The contents of this e-mail (including any attachments) are
>> >> confidential and may be legally privileged. If you are not the
>> >> intended recipient of this e-mail, any disclosure, copying,
>> >> distribution or use of its contents is strictly prohibited, and you
>> >> should please notify the sender immediately and then delete it
>> (including
>> >> any attachments) from your system. Thank you.
>> >> Am 19.12.2019 um 17:05 schrieb Andrija Panic <
>> andrija.panic@gmail.com>:
>> >>
>> >> Hi All,
>> >>
>> >> I’d like to put myself forward as release manager for 4.14. The
>> >> 4.14 releases will be the next major version LTS release and will
>> be
>> >> supported for 20 months per the LTS manifesto [2].
>> >>
>> >> I'll have support from Rohit/Daan/Paul during the process and
>> anyone
>> >> else interested is most welcome to join the effort.
>> >>
>> >> The proposed timeline (possibly a bit too ambitious) is as follows:
>> >>
>> >> ######################################
>> >> 24.Jan 2019 --> Code freeze
>> >> 31.Jan-07.Feb 2019 --> Cut first RC
>> >> 21.Feb 2019+ --> Release
>> >> ######################################
>> >>
>> >> As usual, kindly note the following "behaviour" to be in place
>> >> (pretty much copy/paste from the related 4.11 email from Rohit):
>> >>
>> >> ######################################
>> >> 1. After the freeze date (expected 24th Jan) until GA release,
>> >> features will not be allowed and fixes will be only as long as
>> there
>> >> are blocker issues outstanding. Fixes for other issues will be
>> >> individually judged on their merit and risk.
>> >> 2. RM will triage/report critical and blocker bugs for 4.14 and
>> >> encourage people to get them fixed.
>> >> 3. RM will create RCs and start voting once blocker bugs are
>> cleared
>> >> and baseline smoke test results are on par with previous 4.13 smoke
>> >> test
>> >> results
>> >> test results.
>> >> 4. RM will allocate at least a week for branch stabilization and
>> testing.
>> >> At the earliest, on 31st January, RM will put 4.14.0.0-rc1 for
>> >> voting
>> >> from
>> >> the 4.14 branch, and master will be open to accepting new features.
>> >> 5. RM will repeat 2-4 as required. Voting/testing of -rc2, -rc3 and
>> >> so
>> >> on,
>> >> will be created as required
>> >> 6. Once vote passes - RM will continue with the release procedures
>> [1].
>> >>
>> >> I’d like the community (including myself and colleagues) to:
>> >> - Up to 24th January, community members try to review, test and
>> >> merge as many fixes as possible, being super-diligent to not
>> >> de-stabilize the master branch.
>> >> - Engage with gatekeepers to get your PRs reviewed, tested and
>> >> merged (currently myself, Rohit, Daan and Paul, others are welcome
>> >> to engage as well). Do not merge the PRs
>> >> - A pull request may be reverted where the author(s) are not
>> >> responding and authors may be asked to re-submit their changes
>> after
>> >> taking suitable remedies.
>> >>
>> >> [1]
>> >>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu
>> >> re
>> >> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> >> ######################################
>> >> --
>> >>
>> >>
>> >> Andrija Panić
>> >>
>> >>
>> >>
>> >>
>>
>> --
>>
>> Andrija Panić
>>
>>
>>
>
> --
>
> Andrija Panić
>
--
Andrija Panić
Re: [PROPOSE] RM for 4.14
Posted by Andrija Panic <an...@gmail.com>.
Hi all,
with regards to the freeze date, it seems that we'll have to push it back a
bit, again.
I have not had time to do much myself (will rejoin the effort starting from
Monday), but I can see that we have reduced total number of Milestone items
(for both 4.14 and 4.13.1) by 1/3 (we went from ~60 to ~40) - this leaves
us with roughly another **2 weeks** to finish off the remaining milestone
items. Next time I might propose a very "pessimistic" dates, instead of
overly optimistic (that original dates I proposed seem to be), to avoid
postponing the release by this amount of time.
I hope that everyone finds this OK - at the end of the day, WHAT we release
it what's going to be remembered, not WHEN we released it.
As usual, I will follow up here once we are close to the freeze date.
If anyone has any concerns, please let me know.
Thanks,
Andrija
On Wed, 22 Jan 2020 at 15:18, Boris Stoyanov <bo...@shapeblue.com>
wrote:
> +1, I'd really love to see some of the PRs with the 4.14 milestone in but
> I need more time to test them.
>
> Bobby.
>
> On 22.01.20, 13:22, "Andrija Panic" <an...@gmail.com> wrote:
>
> Hi all,
>
> I’d like to push back the freeze date for at least a week vs. what's
> previously proposed since I’ve been contacted by a few people who have
> some
> PRs they like to get closed off. If of any interest, I’m away
> 27th-31th
> January (but will check emails occasionally).
>
> I'll follow-up here on the freeze date.
>
> Thanks,
> Andrija
>
>
>
> boris.stoyanov@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London WC2E 9DPUK
> @shapeblue
>
>
>
> On Fri, 20 Dec 2019 at 16:30, Andrija Panic <an...@gmail.com>
> wrote:
>
> > Hi guys
> >
> > Sven,
> > read the original email pls (last part of it) - we will need to fix
> some
> > bugs, test other people fixes as applicable, etc - "usual" day to dev
> > stuff.
> >
> > Gabriel,
> >
> > thx for the help (in advance! ), let's aim to improve the page
> during this
> > release, I'll surely raise this if/when I see a problem (considering
> this
> > is my first time but I will also have help from other experienced
> guys as
> > already explained).
> >
> > As for the LTS discussion, I would add that there is an "awful" lot
> of new
> > stuff planned for this releases, making it a more suitable candidate
> for
> > LTS then for non-LTS, if that makes sense.
> >
> > Anyway, looking forward working with all you guys on this one!
> >
> > Best,
> > Andrija
> >
> >
> >
> > On Fri, 20 Dec 2019, 12:24 Sven Vogel, <S....@ewerk.com> wrote:
> >
> >> @Paul @Gabriel
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
> >>
> >>
> >> This seems the link for the release process. I read them. how is it
> >> possible to engage in this process? I don’t know. Is it useful. I
> would
> >> come more into and learn it.
> >>
> >>
> >>
> >>
> >> Von meinem iPhone gesendet
> >>
> >>
> >> __
> >>
> >> Sven Vogel
> >> Teamlead Platform
> >>
> >> EWERK DIGITAL GmbH
> >> Brühl 24, D-04109 Leipzig
> >> P +49 341 42649 - 99
> >> F +49 341 42649 - 98
> >> S.Vogel@ewerk.com
> >> www.ewerk.com
> >>
> >> Geschäftsführer:
> >> Dr. Erik Wende, Hendrik Schubert, Frank Richter
> >> Registergericht: Leipzig HRB 9065
> >>
> >> Support:
> >> +49 341 42649 555
> >>
> >> Zertifiziert nach:
> >> ISO/IEC 27001:2013
> >> DIN EN ISO 9001:2015
> >> DIN ISO/IEC 20000-1:2011
> >>
> >> ISAE 3402 Typ II Assessed
> >>
> >> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> >> https://www.linkedin.com/company/ewerk-group> | Xing<
> >> https://www.xing.com/company/ewerk> | Twitter<
> >> https://twitter.com/EWERK_Group> | Facebook<
> >> https://de-de.facebook.com/EWERK.IT/>
> >>
> >> Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH
> auf
> >> die EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem
> Namen:
> >> EWERK DIGITAL GmbH, für weitere Informationen klicken Sie hier<
> >> https://www.ewerk.com/ewerkdigital>.
> >>
> >> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
> >>
> >> Disclaimer Privacy:
> >> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter
> Dateien)
> >> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie
> nicht der
> >> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> >> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt.
> Bitte
> >> informieren Sie in diesem Fall unverzüglich den Absender und
> löschen Sie
> >> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
> System.
> >> Vielen Dank.
> >>
> >> The contents of this e-mail (including any attachments) are
> confidential
> >> and may be legally privileged. If you are not the intended
> recipient of
> >> this e-mail, any disclosure, copying, distribution or use of its
> contents
> >> is strictly prohibited, and you should please notify the sender
> immediately
> >> and then delete it (including any attachments) from your system.
> Thank you.
> >>
> >> Am 20.12.2019 um 12:01 schrieb Gabriel Beims Bräscher <
> >> gabrascher@gmail.com>:
> >>
> >> Hi Paul, thanks for the clarification.
> >> First of all, count with me for any help with the 4.14 release
> process :-)
> >>
> >> I have no problem with 4.14 becoming the next LTS, having 2 LTS
> releases
> >> per year sounds good. It is worth to mention that with the past
> releases
> >> holding +200 commits it was quite a challenge to ensure stability.
> Just
> >> raising attention to the fact that we might need to support 2 LTS in
> >> parallel for longer than on prior LTS (not a problem for me). Hope
> that we
> >> can keep a nice balance between new features and stability.
> >>
> >> Additionally, we have some outdated documents regarding the
> releasing
> >> process and it must be reviewed and updated accordingly. This was a
> >> problem
> >> for me when releasing 4.12.
> >> For the future, I would like to see a discussion around the
> releasing
> >> process and the pace for future releases. With such discussion
> formalized
> >> and documented, we can make life easier for RMs and also give a
> better
> >> perspective of the project status and roadmap to users/developers.
> >>
> >> Kind regards,
> >> Gabriel.
> >>
> >> Em qui., 19 de dez. de 2019 às 19:58, Greg Goodrich <
> >> GGoodrich@ippathways.com> escreveu:
> >>
> >> A minor note that those 4.14 dates should all be 2020, not 2019
> >>
> >> --
> >> Greg Goodrich | IP Pathways
> >> Senior Developer
> >> 3600 109th Street | Urbandale, IA 50322
> >> p. 515.422.9346 | e. ggoodrich@ippathways.com<mailto:
> jfry@ippathways.com>
> >>
> >> On Dec 19, 2019, at 12:30 PM, Paul Angus <paul.angus@shapeblue.com
> >> <mailto:
> >> paul.angus@shapeblue.com>> wrote:
> >>
> >> I can answer that one...
> >>
> >> The 'plan' was always 2 new LTS branches a year - effectively
> summer and
> >> winter. Remember at the time, some members of the community were
> going
> >> for
> >> a release every month. So the idea was - whatever the branch was the
> >> current branch at the time that an LTS was due, that branch would
> get some
> >> 'extra treatment' and be supported for a few years rather than a few
> >> months.
> >>
> >> Very importantly, the post x.x.0 LTS releases were to have no new
> features
> >> - just bugfixes. So larger organisations with stricter change
> control,
> >> their own documentation and their own integrations, could stay on a
> >> 'supported' branch but still get bug fixes in releases, without
> having to
> >> worry about, test or document new features constantly.
> >>
> >> (I'll hand-wave over the fact that one person's feature is another
> >> person's improvement, is another person's bugfix)
> >>
> >> Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1
> with all
> >> critical/blocker/major bugfixes in it (probably as soon as enough
> people
> >> have recovered from a 4.14 release cycle) but it can't have any new
> >> features in it.
> >>
> >> So looking forward, if someone wants a 4.15 release in (say) April,
> then
> >> the 'summer' LTS branch (July/August time) will be 4.16, if not,
> then the
> >> summer LTS release would be 4.15
> >>
> >> I hope that helps 😊
> >>
> >>
> >> Kind regards
> >>
> >> Paul.
> >>
> >>
> >> paul.angus@shapeblue.com<ma...@shapeblue.com>
> >> www.shapeblue.com<http://www.shapeblue.com>
> >> Amadeus House, Floral Street, London WC2E 9DPUK
> >> @shapeblue
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Gabriel Beims Bräscher <ga...@gmail.com>
> >> Sent: 19 December 2019 16:59
> >> To: dev <de...@cloudstack.apache.org>
> >> Subject: Re: [PROPOSE] RM for 4.14
> >>
> >> Hello Andrija,
> >>
> >> That is always good news to have contributors stepping up and
> getting new
> >> releases done. We definitely need a release (either a major or a
> 4.13.1.0)
> >> to keep the project traction. However, I would like to understand
> why
> >> 4.14.0.0 is being considered an LTS release.
> >> As far as I know, the next major release was supposed to be a
> regular
> >> (non-LTS) release in the midle of the current LTS and next one LTS.
> Our
> >> current LTS 4.13.0.0 is young and with still has some room for
> bugfixes.
> >>
> >> For reference, here follows the Release Calendar, more details at
> [1].
> >> 4.9.2.0, LTS, released at 15 December 2016, EOL 1 July 2018
> 4.9.3.0, LTS,
> >> released at 11 September 2017, EOL 1 July 2018 4.11.0.0, LTS,
> released at
> >> 12 February 2018, EOL July 2019 4.12.0.0, Regular, released at 4
> April
> >> 2019, N/A 4.13.0.0, LTS, released at 24 September 2019, Current LTS
> >> 4.14.0.0, LTS/Regular, planned to 21.Feb 2019+
> >>
> >> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> >>
> >> Regards,
> >> Gabriel.
> >>
> >>
> >> Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel <S.Vogel@ewerk.com
> >
> >> escreveu:
> >>
> >> Hi Andrija,
> >>
> >> How can I help and engage in this process?
> >>
> >> Cheers
> >>
> >> Sven
> >>
> >>
> >>
> >> __
> >>
> >> Sven Vogel
> >> Teamlead Platform
> >>
> >> EWERK DIGITAL GmbH
> >> Brühl 24, D-04109 Leipzig
> >> P +49 341 42649 - 99
> >> F +49 341 42649 - 98
> >> S.Vogel@ewerk.com
> >> www.ewerk.com
> >>
> >> Geschäftsführer:
> >> Dr. Erik Wende, Hendrik Schubert, Frank Richter
> >> Registergericht: Leipzig HRB 9065
> >>
> >> Zertifiziert nach:
> >> ISO/IEC 27001:2013
> >> DIN EN ISO 9001:2015
> >> DIN ISO/IEC 20000-1:2011
> >>
> >> EWERK-Blog | LinkedIn | Xing | Twitter | Facebook
> >>
> >> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
> >>
> >> Disclaimer Privacy:
> >> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter
> Dateien)
> >> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie
> nicht
> >> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche
> Offenlegung,
> >> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt.
> Bitte
> >> informieren Sie in diesem Fall unverzüglich den Absender und löschen
> >> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von
> Ihrem
> >> System.
> >> Vielen Dank.
> >>
> >> The contents of this e-mail (including any attachments) are
> >> confidential and may be legally privileged. If you are not the
> >> intended recipient of this e-mail, any disclosure, copying,
> >> distribution or use of its contents is strictly prohibited, and you
> >> should please notify the sender immediately and then delete it
> (including
> >> any attachments) from your system. Thank you.
> >> Am 19.12.2019 um 17:05 schrieb Andrija Panic <
> andrija.panic@gmail.com>:
> >>
> >> Hi All,
> >>
> >> I’d like to put myself forward as release manager for 4.14. The
> >> 4.14 releases will be the next major version LTS release and will be
> >> supported for 20 months per the LTS manifesto [2].
> >>
> >> I'll have support from Rohit/Daan/Paul during the process and anyone
> >> else interested is most welcome to join the effort.
> >>
> >> The proposed timeline (possibly a bit too ambitious) is as follows:
> >>
> >> ######################################
> >> 24.Jan 2019 --> Code freeze
> >> 31.Jan-07.Feb 2019 --> Cut first RC
> >> 21.Feb 2019+ --> Release
> >> ######################################
> >>
> >> As usual, kindly note the following "behaviour" to be in place
> >> (pretty much copy/paste from the related 4.11 email from Rohit):
> >>
> >> ######################################
> >> 1. After the freeze date (expected 24th Jan) until GA release,
> >> features will not be allowed and fixes will be only as long as there
> >> are blocker issues outstanding. Fixes for other issues will be
> >> individually judged on their merit and risk.
> >> 2. RM will triage/report critical and blocker bugs for 4.14 and
> >> encourage people to get them fixed.
> >> 3. RM will create RCs and start voting once blocker bugs are cleared
> >> and baseline smoke test results are on par with previous 4.13 smoke
> >> test
> >> results
> >> test results.
> >> 4. RM will allocate at least a week for branch stabilization and
> testing.
> >> At the earliest, on 31st January, RM will put 4.14.0.0-rc1 for
> >> voting
> >> from
> >> the 4.14 branch, and master will be open to accepting new features.
> >> 5. RM will repeat 2-4 as required. Voting/testing of -rc2, -rc3 and
> >> so
> >> on,
> >> will be created as required
> >> 6. Once vote passes - RM will continue with the release procedures
> [1].
> >>
> >> I’d like the community (including myself and colleagues) to:
> >> - Up to 24th January, community members try to review, test and
> >> merge as many fixes as possible, being super-diligent to not
> >> de-stabilize the master branch.
> >> - Engage with gatekeepers to get your PRs reviewed, tested and
> >> merged (currently myself, Rohit, Daan and Paul, others are welcome
> >> to engage as well). Do not merge the PRs
> >> - A pull request may be reverted where the author(s) are not
> >> responding and authors may be asked to re-submit their changes after
> >> taking suitable remedies.
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu
> >> re
> >> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> >> ######################################
> >> --
> >>
> >>
> >> Andrija Panić
> >>
> >>
> >>
> >>
>
> --
>
> Andrija Panić
>
>
>
--
Andrija Panić
Re: [PROPOSE] RM for 4.14
Posted by Boris Stoyanov <bo...@shapeblue.com>.
+1, I'd really love to see some of the PRs with the 4.14 milestone in but I need more time to test them.
Bobby.
On 22.01.20, 13:22, "Andrija Panic" <an...@gmail.com> wrote:
Hi all,
I’d like to push back the freeze date for at least a week vs. what's
previously proposed since I’ve been contacted by a few people who have some
PRs they like to get closed off. If of any interest, I’m away 27th-31th
January (but will check emails occasionally).
I'll follow-up here on the freeze date.
Thanks,
Andrija
boris.stoyanov@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London WC2E 9DPUK
@shapeblue
On Fri, 20 Dec 2019 at 16:30, Andrija Panic <an...@gmail.com> wrote:
> Hi guys
>
> Sven,
> read the original email pls (last part of it) - we will need to fix some
> bugs, test other people fixes as applicable, etc - "usual" day to dev
> stuff.
>
> Gabriel,
>
> thx for the help (in advance! ), let's aim to improve the page during this
> release, I'll surely raise this if/when I see a problem (considering this
> is my first time but I will also have help from other experienced guys as
> already explained).
>
> As for the LTS discussion, I would add that there is an "awful" lot of new
> stuff planned for this releases, making it a more suitable candidate for
> LTS then for non-LTS, if that makes sense.
>
> Anyway, looking forward working with all you guys on this one!
>
> Best,
> Andrija
>
>
>
> On Fri, 20 Dec 2019, 12:24 Sven Vogel, <S....@ewerk.com> wrote:
>
>> @Paul @Gabriel
>>
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>>
>>
>> This seems the link for the release process. I read them. how is it
>> possible to engage in this process? I don’t know. Is it useful. I would
>> come more into and learn it.
>>
>>
>>
>>
>> Von meinem iPhone gesendet
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> EWERK DIGITAL GmbH
>> Brühl 24, D-04109 Leipzig
>> P +49 341 42649 - 99
>> F +49 341 42649 - 98
>> S.Vogel@ewerk.com
>> www.ewerk.com
>>
>> Geschäftsführer:
>> Dr. Erik Wende, Hendrik Schubert, Frank Richter
>> Registergericht: Leipzig HRB 9065
>>
>> Support:
>> +49 341 42649 555
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 20000-1:2011
>>
>> ISAE 3402 Typ II Assessed
>>
>> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
>> https://www.linkedin.com/company/ewerk-group> | Xing<
>> https://www.xing.com/company/ewerk> | Twitter<
>> https://twitter.com/EWERK_Group> | Facebook<
>> https://de-de.facebook.com/EWERK.IT/>
>>
>> Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH auf
>> die EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem Namen:
>> EWERK DIGITAL GmbH, für weitere Informationen klicken Sie hier<
>> https://www.ewerk.com/ewerkdigital>.
>>
>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>
>> Disclaimer Privacy:
>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
>> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
>> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
>> Vielen Dank.
>>
>> The contents of this e-mail (including any attachments) are confidential
>> and may be legally privileged. If you are not the intended recipient of
>> this e-mail, any disclosure, copying, distribution or use of its contents
>> is strictly prohibited, and you should please notify the sender immediately
>> and then delete it (including any attachments) from your system. Thank you.
>>
>> Am 20.12.2019 um 12:01 schrieb Gabriel Beims Bräscher <
>> gabrascher@gmail.com>:
>>
>> Hi Paul, thanks for the clarification.
>> First of all, count with me for any help with the 4.14 release process :-)
>>
>> I have no problem with 4.14 becoming the next LTS, having 2 LTS releases
>> per year sounds good. It is worth to mention that with the past releases
>> holding +200 commits it was quite a challenge to ensure stability. Just
>> raising attention to the fact that we might need to support 2 LTS in
>> parallel for longer than on prior LTS (not a problem for me). Hope that we
>> can keep a nice balance between new features and stability.
>>
>> Additionally, we have some outdated documents regarding the releasing
>> process and it must be reviewed and updated accordingly. This was a
>> problem
>> for me when releasing 4.12.
>> For the future, I would like to see a discussion around the releasing
>> process and the pace for future releases. With such discussion formalized
>> and documented, we can make life easier for RMs and also give a better
>> perspective of the project status and roadmap to users/developers.
>>
>> Kind regards,
>> Gabriel.
>>
>> Em qui., 19 de dez. de 2019 às 19:58, Greg Goodrich <
>> GGoodrich@ippathways.com> escreveu:
>>
>> A minor note that those 4.14 dates should all be 2020, not 2019
>>
>> --
>> Greg Goodrich | IP Pathways
>> Senior Developer
>> 3600 109th Street | Urbandale, IA 50322
>> p. 515.422.9346 | e. ggoodrich@ippathways.com<ma...@ippathways.com>
>>
>> On Dec 19, 2019, at 12:30 PM, Paul Angus <paul.angus@shapeblue.com
>> <mailto:
>> paul.angus@shapeblue.com>> wrote:
>>
>> I can answer that one...
>>
>> The 'plan' was always 2 new LTS branches a year - effectively summer and
>> winter. Remember at the time, some members of the community were going
>> for
>> a release every month. So the idea was - whatever the branch was the
>> current branch at the time that an LTS was due, that branch would get some
>> 'extra treatment' and be supported for a few years rather than a few
>> months.
>>
>> Very importantly, the post x.x.0 LTS releases were to have no new features
>> - just bugfixes. So larger organisations with stricter change control,
>> their own documentation and their own integrations, could stay on a
>> 'supported' branch but still get bug fixes in releases, without having to
>> worry about, test or document new features constantly.
>>
>> (I'll hand-wave over the fact that one person's feature is another
>> person's improvement, is another person's bugfix)
>>
>> Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1 with all
>> critical/blocker/major bugfixes in it (probably as soon as enough people
>> have recovered from a 4.14 release cycle) but it can't have any new
>> features in it.
>>
>> So looking forward, if someone wants a 4.15 release in (say) April, then
>> the 'summer' LTS branch (July/August time) will be 4.16, if not, then the
>> summer LTS release would be 4.15
>>
>> I hope that helps 😊
>>
>>
>> Kind regards
>>
>> Paul.
>>
>>
>> paul.angus@shapeblue.com<ma...@shapeblue.com>
>> www.shapeblue.com<http://www.shapeblue.com>
>> Amadeus House, Floral Street, London WC2E 9DPUK
>> @shapeblue
>>
>>
>>
>>
>> -----Original Message-----
>> From: Gabriel Beims Bräscher <ga...@gmail.com>
>> Sent: 19 December 2019 16:59
>> To: dev <de...@cloudstack.apache.org>
>> Subject: Re: [PROPOSE] RM for 4.14
>>
>> Hello Andrija,
>>
>> That is always good news to have contributors stepping up and getting new
>> releases done. We definitely need a release (either a major or a 4.13.1.0)
>> to keep the project traction. However, I would like to understand why
>> 4.14.0.0 is being considered an LTS release.
>> As far as I know, the next major release was supposed to be a regular
>> (non-LTS) release in the midle of the current LTS and next one LTS. Our
>> current LTS 4.13.0.0 is young and with still has some room for bugfixes.
>>
>> For reference, here follows the Release Calendar, more details at [1].
>> 4.9.2.0, LTS, released at 15 December 2016, EOL 1 July 2018 4.9.3.0, LTS,
>> released at 11 September 2017, EOL 1 July 2018 4.11.0.0, LTS, released at
>> 12 February 2018, EOL July 2019 4.12.0.0, Regular, released at 4 April
>> 2019, N/A 4.13.0.0, LTS, released at 24 September 2019, Current LTS
>> 4.14.0.0, LTS/Regular, planned to 21.Feb 2019+
>>
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>>
>> Regards,
>> Gabriel.
>>
>>
>> Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel <S....@ewerk.com>
>> escreveu:
>>
>> Hi Andrija,
>>
>> How can I help and engage in this process?
>>
>> Cheers
>>
>> Sven
>>
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> EWERK DIGITAL GmbH
>> Brühl 24, D-04109 Leipzig
>> P +49 341 42649 - 99
>> F +49 341 42649 - 98
>> S.Vogel@ewerk.com
>> www.ewerk.com
>>
>> Geschäftsführer:
>> Dr. Erik Wende, Hendrik Schubert, Frank Richter
>> Registergericht: Leipzig HRB 9065
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 20000-1:2011
>>
>> EWERK-Blog | LinkedIn | Xing | Twitter | Facebook
>>
>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>
>> Disclaimer Privacy:
>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht
>> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>> informieren Sie in diesem Fall unverzüglich den Absender und löschen
>> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
>> System.
>> Vielen Dank.
>>
>> The contents of this e-mail (including any attachments) are
>> confidential and may be legally privileged. If you are not the
>> intended recipient of this e-mail, any disclosure, copying,
>> distribution or use of its contents is strictly prohibited, and you
>> should please notify the sender immediately and then delete it (including
>> any attachments) from your system. Thank you.
>> Am 19.12.2019 um 17:05 schrieb Andrija Panic <an...@gmail.com>:
>>
>> Hi All,
>>
>> I’d like to put myself forward as release manager for 4.14. The
>> 4.14 releases will be the next major version LTS release and will be
>> supported for 20 months per the LTS manifesto [2].
>>
>> I'll have support from Rohit/Daan/Paul during the process and anyone
>> else interested is most welcome to join the effort.
>>
>> The proposed timeline (possibly a bit too ambitious) is as follows:
>>
>> ######################################
>> 24.Jan 2019 --> Code freeze
>> 31.Jan-07.Feb 2019 --> Cut first RC
>> 21.Feb 2019+ --> Release
>> ######################################
>>
>> As usual, kindly note the following "behaviour" to be in place
>> (pretty much copy/paste from the related 4.11 email from Rohit):
>>
>> ######################################
>> 1. After the freeze date (expected 24th Jan) until GA release,
>> features will not be allowed and fixes will be only as long as there
>> are blocker issues outstanding. Fixes for other issues will be
>> individually judged on their merit and risk.
>> 2. RM will triage/report critical and blocker bugs for 4.14 and
>> encourage people to get them fixed.
>> 3. RM will create RCs and start voting once blocker bugs are cleared
>> and baseline smoke test results are on par with previous 4.13 smoke
>> test
>> results
>> test results.
>> 4. RM will allocate at least a week for branch stabilization and testing.
>> At the earliest, on 31st January, RM will put 4.14.0.0-rc1 for
>> voting
>> from
>> the 4.14 branch, and master will be open to accepting new features.
>> 5. RM will repeat 2-4 as required. Voting/testing of -rc2, -rc3 and
>> so
>> on,
>> will be created as required
>> 6. Once vote passes - RM will continue with the release procedures [1].
>>
>> I’d like the community (including myself and colleagues) to:
>> - Up to 24th January, community members try to review, test and
>> merge as many fixes as possible, being super-diligent to not
>> de-stabilize the master branch.
>> - Engage with gatekeepers to get your PRs reviewed, tested and
>> merged (currently myself, Rohit, Daan and Paul, others are welcome
>> to engage as well). Do not merge the PRs
>> - A pull request may be reverted where the author(s) are not
>> responding and authors may be asked to re-submit their changes after
>> taking suitable remedies.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu
>> re
>> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> ######################################
>> --
>>
>>
>> Andrija Panić
>>
>>
>>
>>
--
Andrija Panić