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 2019/12/19 16:05:26 UTC
[PROPOSE] RM for 4.14
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+Procedure
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
######################################
--
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ć
Re: [PROPOSE] RM for 4.14
Posted by Andrija Panic <an...@gmail.com>.
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 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ć
>
>
>
>
Re: [PROPOSE] RM for 4.14
Posted by Sven Vogel <S....@ewerk.com>.
@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 <ga...@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ć
Re: [PROPOSE] RM for 4.14
Posted by Gabriel Beims Bräscher <ga...@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ć
>
>
>
Re: [PROPOSE] RM for 4.14
Posted by Greg Goodrich <GG...@ippathways.com>.
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 <pa...@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ć
RE: [PROPOSE] RM for 4.14
Posted by Paul Angus <pa...@shapeblue.com>.
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
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ć
>
Re: [PROPOSE] RM for 4.14
Posted by Gabriel Beims Bräscher <ga...@gmail.com>.
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+Procedure
> > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > ######################################
> > --
> >
> >
> > Andrija Panić
>
Re: [PROPOSE] RM for 4.14
Posted by Sven Vogel <S....@ewerk.com>.
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+Procedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> ######################################
> --
>
>
> Andrija Panić