[GitHub] [cloudstack-primate] rhtyd opened a new pull request #80: Update issue templates

[GitBox]

rhtyd opened a new pull request #80: Update issue templates
URL: https://github.com/apache/cloudstack-primate/pull/80
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [cloudstack-primate] rhtyd opened a new pull request #79: Update issue templates

[GitBox]

rhtyd opened a new pull request #79: Update issue templates
URL: https://github.com/apache/cloudstack-primate/pull/79
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [PROPOSE] RM for 4.14

[Greg Goodrich]

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. ggoodr...@ippathways.com

On Dec 19, 2019, at 12:30 PM, Paul Angus 
mailto:paul.an...@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.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




-Original Message-
From: Gabriel Beims Bräscher 
Sent: 19 December 2019 16:59
To: dev 
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 
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.vo...@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 2-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 :

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
###

RE: [PROPOSE] RM for 4.14

[Paul Angus]

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.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Gabriel Beims Bräscher  
Sent: 19 December 2019 16:59
To: dev 
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 
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.vo...@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 2-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 :
> >
> > 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. 

Re: [PROPOSE] RM for 4.14

[Gabriel Beims Bräscher]

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 
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.vo...@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 2-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 :
> >
> > 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

Re: [PROPOSE] RM for 4.14

[Sven Vogel]

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.vo...@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 2-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 :
>
> 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ć

[PROPOSE] RM for 4.14

[Andrija Panic]

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ć

[GitHub] [cloudstack-primate] RitchieVincent opened a new pull request #78: Resource download popup

[GitBox]

RitchieVincent opened a new pull request #78: Resource download popup
URL: https://github.com/apache/cloudstack-primate/pull/78
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services