You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by John Burwell <jo...@shapeblue.com> on 2016/01/15 19:48:36 UTC

[PROPOSAL] LTS Release Cycle

Motivation
========

The current monthly release cycle addresses the needs of users focused on deploying new functionality as quickly as possible. It does not address the needs of users oriented towards stability rather than new functionality. These users typically employ QA processes to comply with corporate policy and/or regulatory requirements. To maintain a growing, thriving community, we must address the needs of both user types. Therefore, I propose that we overlay a LTS release cycle onto the monthly release cycle to address the needs of stability-oriented users with minimal to no impact on the monthly release cycle. This proposed LTS release cycle has the following goals:

* Prefer Stability to New Functionality: Deliver releases that only address defects and CVEs. This narrowly focused change scope greatly reduces the upgrade risk/operational impact and shorter internal QA cycles.
* Reliable Release Lifetimes: Embracing a time-based release strategy, the LTS release cycle will provide users with a reliable support time frames. Users can use these time frames provide users with an 20 month window in which to plan upgrades.
* Support Sustainability: With a defined end of support for LTS releases and a maximum of two (2) LTS releases under active maintenance at any given time, community members can better plan their commitments to release support activities. We also have a agreed upon policy for release end-of-life (EOL) to debate about continuing work on old releases.

Proposed Process
==============

LTS release branches will be cut twice year on 1 Jan and 1 July from the tag of the most recent monthly release. The branch will be named <base version>-LTS and each LTS release will be versioned in the form of <base version>-<LTS revision number>. For example, if we cut an LTS branch based on 4.7.0, the branch would be named 4.7.0-LTS and the version of the first LTS release would be 4.7.0-0, the second would be 4.7.0-1, etc. This release naming convention differentiates LTS and monthly releases, communicates the version on which the LTS release is based, and allows the maintenance releases for monthly releases without version number contention/conflict. Finally, like master, an LTS branch would be always deployable following its initial release. While it is unlikely that LTS users would deploy from the branch, the quality discipline of this requirement will benefit the long term stability of LTS releases. All PRs targeting an LTS would require two LGTMs in order to be merged.

The following are the types of changes that would permitted and guarantees provided to users:

* No features or enhancements would be backported to LTS release branches.
* Database changes would be limited to those required to address the backported defect fixes.
* Support for the release/version of the following components from the release on which the LTS is based throughout the entire release cycle:
* MySQL/MariaDB
* JDK/JRE
* Linux distributions
* API compatibility for between all LTS revisions. API changes would be limited to those required to fix defects or address security issues.

An LTS release would have a twenty (20) month lifetime from the date the release branch is cut. This support period allows up to two (2) months of branch stabilization before initial release with a minimum of eighteen (18) months of availability for deployment. LTS releases would have the following support periods:

* 0-14 months: backport all defect fixes in the scope of the LTS release functionality; fix all blocker and critical priority defects identified in the branch
* 14-20 months: backport only CVE fixes in the scope of the LTS release functionality; fix all blocker priority defects in the branch

Defect fixes that originate in an LTS branch will be pulled forward to master only. Finally, an LTS branch should be release the fewest times necessary to deliver fixes in a relatively timely manner. Therefore, LTS releases will be triggered based on the number of pending of fixes and their severity with no defect fix awaiting release more than forty-five (45) days. CVE fixes would trigger an immediate release of an LTS branch.

Resourcing and Proposed Timeline
===========================

Broad community support is vital to guarantee the twenty (20) month support period for each LTS branch. Given the ebbs and flows of contribution and committer priorities, ShapeBlue will provide a release manager, as well as, engineering support to fill any contribution gaps to ensure that the community fulfills LTS commitments.

In order to prepare for supporting LTS releases, we would need to complete the following items:

1. All tools that do version number comparisons would be made aware of the LTS versioning scheme
2. Officially support running the management server on Java 8 since Java 7 has been EOL since last April [1] (i.e. compile to 1.7 with the Java 1.8 compiler and run on Java 1.8). Providing a 20-month support window on an EOL JVM is an unacceptable security risk.
3. Update the wiki and website to explain the new release cycle and help users decide which release type suits their needs
4. Define an initial test plan for LTS stabilization
5. Agree on the definitions of ticket severities

In order to address these items and start on a regular rhythm, I propose that first LTS cycle begin on 1 July 2015. In the interim, we would continue to ship critical bug fixes from the 4.5 release as this release seems to be the most commonly deployed in the community.

Together, the monthly and LTS release cycles address the needs of the entire Apache CloudStack user community. I believe that the process described in the proposal will yield releases that meet the needs of users requiring release stability without adversely affecting the velocity of the monthly release cycle.

Thanks,
-John

[1]: http://www.oracle.com/technetwork/java/eol-135779.html


[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:      john.burwell@shapeblue.com | t: <mailto:john.burwell@shapeblue.com%20|%20t:>     |      w:      www.shapeblue.com<http://www.shapeblue.com>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagef869f6.png@4b2b18aa.44bcb591]


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.




Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Fwd: [PROPOSAL] LTS Release Cycle

Posted by Ron Wheeler <rw...@artifact-software.com>.

There has been a long discussion about release strategies in the Apache 
Cloudstack forum.
This is an interesting proposal that has been fleshed out to a pretty 
good level of detail.

Although Cloudstack and OFBiz serve very different areas, both could be 
described as critical applications where downtime and instability will 
have very high corporate visibility.
Security is important to both and fixes to underlying third party 
software can come at any time and they may force upgrades to the 
application unexpectedly.
Bugs need to be fixed as well.

They are currently issuing an  official release every month which gets 
new features and bug fixes out quickly but is causing some discomfort 
for the majority of the system administrators who can not keep up with 
that pace given the amount of internal certification required and the 
inability to stand that frequency of maintenance downtime.

This tries to balance the thirst for new features with the need for 
stability and attempts to move the decision about upgrades to the user 
by reducing the pain of not upgrading so often while providing a way for 
those who need the bleeding edge to have access to bug fixes and new 
features quickly.

Ron

-------- Forwarded Message --------

Motivation
========

The current monthly release cycle addresses the needs of users focused 
on deploying new functionality as quickly as possible. It does not 
address the needs of users oriented towards stability rather than new 
functionality. These users typically employ QA processes to comply with 
corporate policy and/or regulatory requirements. To maintain a growing, 
thriving community, we must address the needs of both user types. 
Therefore, I propose that we overlay a LTS release cycle onto the 
monthly release cycle to address the needs of stability-oriented users 
with minimal to no impact on the monthly release cycle. This proposed 
LTS release cycle has the following goals:

* Prefer Stability to New Functionality: Deliver releases that only 
address defects and CVEs. This narrowly focused change scope greatly 
reduces the upgrade risk/operational impact and shorter internal QA cycles.
* Reliable Release Lifetimes: Embracing a time-based release strategy, 
the LTS release cycle will provide users with a reliable support time 
frames. Users can use these time frames provide users with an 20 month 
window in which to plan upgrades.
* Support Sustainability: With a defined end of support for LTS releases 
and a maximum of two (2) LTS releases under active maintenance at any 
given time, community members can better plan their commitments to 
release support activities. We also have a agreed upon policy for 
release end-of-life (EOL) to debate about continuing work on old releases.

Proposed Process
==============

LTS release branches will be cut twice year on 1 Jan and 1 July from the 
tag of the most recent monthly release. The branch will be named <base 
version>-LTS and each LTS release will be versioned in the form of <base 
version>-<LTS revision number>. For example, if we cut an LTS branch 
based on 4.7.0, the branch would be named 4.7.0-LTS and the version of 
the first LTS release would be 4.7.0-0, the second would be 4.7.0-1, 
etc. This release naming convention differentiates LTS and monthly 
releases, communicates the version on which the LTS release is based, 
and allows the maintenance releases for monthly releases without version 
number contention/conflict. Finally, like master, an LTS branch would be 
always deployable following its initial release. While it is unlikely 
that LTS users would deploy from the branch, the quality discipline of 
this requirement will benefit the long term stability of LTS releases. 
All PRs targeting an LTS would require two LGTMs in order to be merged.

The following are the types of changes that would permitted and 
guarantees provided to users:

* No features or enhancements would be backported to LTS release branches.
* Database changes would be limited to those required to address the 
backported defect fixes.
* Support for the release/version of the following components from the 
release on which the LTS is based throughout the entire release cycle:
* MySQL/MariaDB
* JDK/JRE
* Linux distributions
* API compatibility for between all LTS revisions. API changes would be 
limited to those required to fix defects or address security issues.

An LTS release would have a twenty (20) month lifetime from the date the 
release branch is cut. This support period allows up to two (2) months 
of branch stabilization before initial release with a minimum of 
eighteen (18) months of availability for deployment. LTS releases would 
have the following support periods:

* 0-14 months: backport all defect fixes in the scope of the LTS release 
functionality; fix all blocker and critical priority defects identified 
in the branch
* 14-20 months: backport only CVE fixes in the scope of the LTS release 
functionality; fix all blocker priority defects in the branch

Defect fixes that originate in an LTS branch will be pulled forward to 
master only. Finally, an LTS branch should be release the fewest times 
necessary to deliver fixes in a relatively timely manner. Therefore, LTS 
releases will be triggered based on the number of pending of fixes and 
their severity with no defect fix awaiting release more than forty-five 
(45) days. CVE fixes would trigger an immediate release of an LTS branch.

Resourcing and Proposed Timeline
===========================

Broad community support is vital to guarantee the twenty (20) month 
support period for each LTS branch. Given the ebbs and flows of 
contribution and committer priorities, ShapeBlue will provide a release 
manager, as well as, engineering support to fill any contribution gaps 
to ensure that the community fulfills LTS commitments.

In order to prepare for supporting LTS releases, we would need to 
complete the following items:

1. All tools that do version number comparisons would be made aware of 
the LTS versioning scheme
2. Officially support running the management server on Java 8 since Java 
7 has been EOL since last April [1] (i.e. compile to 1.7 with the Java 
1.8 compiler and run on Java 1.8). Providing a 20-month support window 
on an EOL JVM is an unacceptable security risk.
3. Update the wiki and website to explain the new release cycle and help 
users decide which release type suits their needs
4. Define an initial test plan for LTS stabilization
5. Agree on the definitions of ticket severities

In order to address these items and start on a regular rhythm, I propose 
that first LTS cycle begin on 1 July 2015. In the interim, we would 
continue to ship critical bug fixes from the 4.5 release as this release 
seems to be the most commonly deployed in the community.

Together, the monthly and LTS release cycles address the needs of the 
entire Apache CloudStack user community. I believe that the process 
described in the proposal will yield releases that meet the needs of 
users requiring release stability without adversely affecting the 
velocity of the monthly release cycle.

Thanks,
-John

[1]: http://www.oracle.com/technetwork/java/eol-135779.html


ShapeBlue <http://www.shapeblue.com> 	
John Burwell
ShapeBlue

d: 	*+44 (20) 3603 0542 | s: +1 (571) 403-2411 * 
<tel:+44%20%2820%29%203603%200542%20%7C%20s:%20+1%20%28571%29%20403-2411>

e: 	*john.burwell@shapeblue.com | t: * 
<mailto:john.burwell@shapeblue.com%20%7C%20t:> 	 | 	w: 
*www.shapeblue.com* <http://www.shapeblue.com>

a: 	53 Chandos Place, Covent Garden London WC2N 4HS UK

Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue 
Services India LLP is a company incorporated in India and is operated 
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is 
a company incorporated in Brasil and is operated under license from 
Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The 
Republic of South Africa and is traded under license from Shape Blue 
Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are 
intended solely for the use of the individual to whom it is addressed. 
Any views or opinions expressed are solely those of the author and do 
not necessarily represent those of Shape Blue Ltd or related companies. 
If you are not the intended recipient of this email, you must neither 
take any action based upon its contents, nor copy or show it to anyone. 
Please contact the sender if you believe you have received this email in 
error.


Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build 
<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid 
IaaS deployment framework <http://shapeblue.com/csforge/>
CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> | 
CloudStack Software Engineering 
<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support 
<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack 
Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by John Burwell <jo...@shapeblue.com>.

All,

Based on the feedback from Ilya, Erik, and Daan, I have updated my original LTS proposal to clarify that LTS releases are official project deliverables, commit traceability across branches, and RM approval of PRs:

## START ##

Motivation
==========

The current monthly release cycle addresses the needs of users focused on deploying new functionality as quickly as possible.  It does not address the needs of users oriented towards stability rather than new functionality.  These users typically employ QA processes to comply with corporate policy and/or regulatory requirements.  To maintain a growing, thriving community, we must address the needs of both user types.  Therefore, I propose that we overlay a LTS release cycle onto the monthly release cycle to address the needs of stability-oriented users with minimal to no impact on the monthly release cycle.  This proposed LTS release cycle has the following goals:

  * Prefer Stability to New Functionality: Deliver releases that only address defects and CVEs.  This narrowly focused change scope greatly reduces the upgrade risk/operational impact and shorter internal QA cycles.
  * Reliable Release Lifetimes: Embracing a time-based release strategy, the LTS release cycle will provide users with a reliable support time frames.  Users can use these time frames provide users with an 20 month window in which to plan upgrades.
  * Support Sustainability: With a defined end of support for LTS releases and a maximum of two (2) LTS releases under active maintenance at any given time, community members can better plan their commitments to release support activities.  We also have a agreed upon policy for release end-of-life (EOL) to debate about continuing work on old releases.

LTS releases would be official project releases.  Therefore, they would be subject to same release voting requirements and available from the project downloads page.

Proposed Process
================

LTS release branches will be cut twice year on 1 Jan and 1 July based the tag of the most recent monthly release.  The branch will be named <base version>_LTS and each LTS release will be versioned in the form of <base version>_<LTS revision number>.  For example, if we cut an LTS branch based on 4.7.0, the branch would be named 4.7.0_LTS and the version of the first LTS release would be 4.7.0_0, the second would be 4.7.0_1, etc.  This release naming convention differentiates LTS and monthly releases, communicates the version on which the LTS release is based, and allows the maintenance releases for monthly releases without version number contention/conflict.  Finally, like master, an LTS branch would be always deployable following its initial release.  While it is unlikely that LTS users would deploy from the branch, the quality discipline of this requirement will benefit the long term stability of LTS releases.  Like master, all PRs targeting an LTS branch would require two LGTMs (one code review and one independent test), as well as, an LGTM from the branch RM.  A combined code review/test LGTM and an RM LGTM would be acceptable.

The following are the types of changes that would permitted and guarantees provided to users:

  * No features or enhancements would be backported to LTS release branches.
  * Database changes would be limited to those required to address the backported defect fixes.
  * Support for the release/version of the following components from the release on which the LTS is based throughout the entire release cycle:
    * MySQL/MariaDB
    * JDK/JRE
    * Linux distributions
  * API compatibility for between all LTS revisions.  API changes would be limited to those required to fix defects or address security issues.

An LTS release would have a twenty (20) month lifetime from the date the release branch is cut.  This support period allows up to two (2) months of branch stabilization before initial release with a minimum of eighteen (18) months of availability for deployment.  The twenty (20) month LTS lifecycle would be divided into following support periods:

  * 0-2 months (average): Stablization of the LTS branch with fixes based on defects discovered from functional, regression, endurance, and scalability testing.
  * 2-14 months: backport blocker and critical priority defect fixes in the scope of the LTS branch functionality; fix all blocker and critical priority defects identified on the LTS branch
  * 14-20 months: backport only CVE fixes in the scope of the LTS branch functionality; fix all blocker priority defects identified on the LTS branch

Defect fixes that originate in an LTS branch would be pulled forward to master only.  Finally, an LTS branch should be release the fewest times necessary to deliver fixes in a relatively timely manner.  Therefore, LTS releases will be triggered based on the number of pending of fixes and their severity with no defect fix awaiting release more than forty-five (45) days.  CVE fixes would trigger the immediate release of an LTS branch.

Users and developers must be able to verify that all fixes applied to an LTS are carried forward to future releases.  Therefore, any commits backported to an LTS branch from master must merged in a traceable manner.  To demonstrate the feasiblity of using git merge for this purpose, I have put together a gist [1] to create traceability by backporting a change from a master to a maint branch.

Resourcing and Proposed Timeline
================================

Broad community support is vital to guarantee the twenty (20) month support period for each LTS branch.  Given the ebbs and flows of contribution and committer priorities, ShapeBlue will provide a release manager, as well as, engineering support to fill any contribution gaps to ensure that the community fulfills LTS commitments.

In order to prepare for supporting LTS releases, we would need to complete the following items:

  1. All tools that do version number comparisons would be made aware of the LTS versioning scheme
  2. Officially support running the management server on Java 8 since Java 7 has been EOL since last April [1] (i.e. compile to 1.7 with the Java 1.8 compiler and run on Java 1.8).  Providing a 20-month support window on an EOL JVM is an unacceptable security risk.
  3. Update the wiki and website to explain the new release cycle and help users decide which release type suits their needs
  4. Define an initial test plan for LTS stabilization
  5. Agree on the definitions of ticket severities

In order to address these items and start on a regular rhythm, I propose that first LTS cycle begin on 1 July 2016.  In the interim, we would continue to ship critical bug fixes from the 4.5 branch as it seems to be a defacto LTS branch by our users.

Together, the monthly and LTS release cycles address the needs of the entire Apache CloudStack user community.  I believe that the process described in the proposal will yield releases that meet the needs of users requiring release stability without adversely affecting the velocity of the monthly release cycle.

[1]: https://gist.github.com/b06a68193c8f46f41e14
[2]: http://www.oracle.com/technetwork/java/eol-135779.html

## END ##

If no significant issues are raised by COB Friday, 5 Feb 2016, I will open a vote on this proposal Monday, 8 Feb 2015 with the hope of gain agreement on an LTS release cycle by the end of next week (12 Feb 2016).

Thank you again for the great feedback — I think it has greatly improved the proposal,
-John

> On Jan 20, 2016, at 6:56 AM, Daan Hoogland <da...@gmail.com> wrote:
>
> Rohit,
>
> I don't see any reasons beyond lack of discipline, ignorance, and laziness
> in your description. Not of an RM or other individual btw but of the
> community as a whole. In point 1 and 2 you are describing how cherry-pick
> and forward merge are actually the same amount of work. In the case of
> forward merge however we will have a merge commit describing what that work
> was and still a link in later branches to the commit.
>
> Point 3 is actually where we should be proactive. If they don't care we
> should tell them to create a branch against the offending commit and work
> from there.
>
>
> On Wed, Jan 20, 2016 at 11:32 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
>> Based on my long-time experience with maintaining and doing release work
>> on 4.3 and later 4.5, there are many reasons where backporting is needed
>> and forward merge won’t work;
>>
>> 1. Due to high codebase changes mostly due to major refactorings, it is
>> not possible to simply cherry-pick a commit; backporting many times
>> involved writing the fix manually based on the commit diff that I wanted to
>> backport. Cherry-picking becomes impossible if anyone has changed package
>> names, file/directory paths, removed code etc.
>>
>> 2. Forward merging will also start failing (due to same reason as above)
>> as time progress the codebase diverges due to refactoring, new code and any
>> design/architectural changes. The other issue with forward merging is that
>> it would require merging from the oldest branch to the newest, with time
>> there would be several branches (given the monthly pace) between the LTS
>> branch and the future master branch. So, in my experience backporting may
>> become necessary.
>>
>> 3. The bugfix author may not send their fix/PR against old branches, as
>> time progresses developers won’t care much about the older LTS branch(es).
>> Wrt 4.3/4.5 at times I had to backport changes myself after failing to get
>> the original author send the fix against 4.3/4.5 branch. This is expected
>> of developers, as they contribute in our own *free* time and they may not
>> have the time, bandwidth or interest in seeing those fixes in older
>> branches.
>>
>> For example, we’ve 4.7 and 4.8 (upcoming) where forwarding merging will
>> work for sometime, but in 14-20 months the developers may not send
>> bugfix/PRs against 4.7 and expect future RMs to merge them forward as that
>> would require both merge-conflict fixing and testing for all intermediate
>> branches 4.8 to 4.20 (assuming, monthly releases we’ll at least reach 4.20
>> in 14-20 months and I’m not sure if RMs will have time and dedication to
>> test all 12+ releases/branches ). For non-LTS branches, it may not make
>> sense to even have those bugfixes.
>>
>> In my experience (with pseudo LTS branches, 4.3/4.5) and opinion, LTS
>> branches are going to diverge wrt master with time but they are going to
>> have a dead-end.
>>
>> About cherry-picking, the way we’re going git commits/merge at least I’m
>> not able to follow the git history at all, it looks like a mess to me. We
>> talk about ability to trace commits through branches, but I cannot even
>> follow changes in the same branch now (say master). I personally use git
>> diff and git log -p to trace changes using differences now (in files or
>> paths/folders). Cherry-picking is not bad, if done right (always include
>> the git commit ID from where it was picked using -x -s) you can trace it.
>>
>> Regards.
>>
>> [image: ShapeBlue] <http://www.shapeblue.com>
>> Rohit Yadav
>> Software Architect ,  ShapeBlue
>> d:  * | s: +44 203 603 0540* <%7C%20s:%20+44%20203%20603%200540>  |  m:
>> *+91 8826230892* <+91%208826230892>
>> e:  *rohit.yadav@shapeblue.com | t: *
>> <rohit.yadav@shapeblue.com%20%7C%20t:>  |  w:  *www.shapeblue.com*
>> <http://www.shapeblue.com>
>> a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>> Services India LLP is a company incorporated in India and is operated under
>> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
>> company incorporated in Brasil and is operated under license from Shape
>> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
>> a registered trademark.
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error.
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services:
>> IaaS Cloud Design & Build
>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
>> IaaS deployment framework <http://shapeblue.com/csforge/>
>> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> | CloudStack
>> Software Engineering
>> <http://shapeblue.com/cloudstack-software-engineering/>
>> CloudStack Infrastructure Support
>> <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
>> Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
>>
>
>
>
> --
> Daan

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by Daan Hoogland <da...@gmail.com>.

Rohit,

I don't see any reasons beyond lack of discipline, ignorance, and laziness
in your description. Not of an RM or other individual btw but of the
community as a whole. In point 1 and 2 you are describing how cherry-pick
and forward merge are actually the same amount of work. In the case of
forward merge however we will have a merge commit describing what that work
was and still a link in later branches to the commit.

Point 3 is actually where we should be proactive. If they don't care we
should tell them to create a branch against the offending commit and work
from there.


On Wed, Jan 20, 2016 at 11:32 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Based on my long-time experience with maintaining and doing release work
> on 4.3 and later 4.5, there are many reasons where backporting is needed
> and forward merge won’t work;
>
> 1. Due to high codebase changes mostly due to major refactorings, it is
> not possible to simply cherry-pick a commit; backporting many times
> involved writing the fix manually based on the commit diff that I wanted to
> backport. Cherry-picking becomes impossible if anyone has changed package
> names, file/directory paths, removed code etc.
>
> 2. Forward merging will also start failing (due to same reason as above)
> as time progress the codebase diverges due to refactoring, new code and any
> design/architectural changes. The other issue with forward merging is that
> it would require merging from the oldest branch to the newest, with time
> there would be several branches (given the monthly pace) between the LTS
> branch and the future master branch. So, in my experience backporting may
> become necessary.
>
> 3. The bugfix author may not send their fix/PR against old branches, as
> time progresses developers won’t care much about the older LTS branch(es).
> Wrt 4.3/4.5 at times I had to backport changes myself after failing to get
> the original author send the fix against 4.3/4.5 branch. This is expected
> of developers, as they contribute in our own *free* time and they may not
> have the time, bandwidth or interest in seeing those fixes in older
> branches.
>
> For example, we’ve 4.7 and 4.8 (upcoming) where forwarding merging will
> work for sometime, but in 14-20 months the developers may not send
> bugfix/PRs against 4.7 and expect future RMs to merge them forward as that
> would require both merge-conflict fixing and testing for all intermediate
> branches 4.8 to 4.20 (assuming, monthly releases we’ll at least reach 4.20
> in 14-20 months and I’m not sure if RMs will have time and dedication to
> test all 12+ releases/branches ). For non-LTS branches, it may not make
> sense to even have those bugfixes.
>
> In my experience (with pseudo LTS branches, 4.3/4.5) and opinion, LTS
> branches are going to diverge wrt master with time but they are going to
> have a dead-end.
>
> About cherry-picking, the way we’re going git commits/merge at least I’m
> not able to follow the git history at all, it looks like a mess to me. We
> talk about ability to trace commits through branches, but I cannot even
> follow changes in the same branch now (say master). I personally use git
> diff and git log -p to trace changes using differences now (in files or
> paths/folders). Cherry-picking is not bad, if done right (always include
> the git commit ID from where it was picked using -x -s) you can trace it.
>
> Regards.
>
> [image: ShapeBlue] <http://www.shapeblue.com>
> Rohit Yadav
> Software Architect ,  ShapeBlue
> d:  * | s: +44 203 603 0540* <%7C%20s:%20+44%20203%20603%200540>  |  m:
> *+91 8826230892* <+91%208826230892>
> e:  *rohit.yadav@shapeblue.com | t: *
> <rohit.yadav@shapeblue.com%20%7C%20t:>  |  w:  *www.shapeblue.com*
> <http://www.shapeblue.com>
> a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> company incorporated in Brasil and is operated under license from Shape
> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
> a registered trademark.
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error.
>
>
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build
> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
> IaaS deployment framework <http://shapeblue.com/csforge/>
> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> | CloudStack
> Software Engineering
> <http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support
> <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
>



-- 
Daan

Re: [PROPOSAL] LTS Release Cycle

Posted by Rohit Yadav <ro...@shapeblue.com>.

Based on my long-time experience with maintaining and doing release work on 4.3 and later 4.5, there are many reasons where backporting is needed and forward merge won’t work;

1. Due to high codebase changes mostly due to major refactorings, it is not possible to simply cherry-pick a commit; backporting many times involved writing the fix manually based on the commit diff that I wanted to backport. Cherry-picking becomes impossible if anyone has changed package names, file/directory paths, removed code etc.

2. Forward merging will also start failing (due to same reason as above) as time progress the codebase diverges due to refactoring, new code and any design/architectural changes. The other issue with forward merging is that it would require merging from the oldest branch to the newest, with time there would be several branches (given the monthly pace) between the LTS branch and the future master branch. So, in my experience backporting may become necessary.

3. The bugfix author may not send their fix/PR against old branches, as time progresses developers won’t care much about the older LTS branch(es). Wrt 4.3/4.5 at times I had to backport changes myself after failing to get the original author send the fix against 4.3/4.5 branch. This is expected of developers, as they contribute in our own *free* time and they may not have the time, bandwidth or interest in seeing those fixes in older branches.

For example, we’ve 4.7 and 4.8 (upcoming) where forwarding merging will work for sometime, but in 14-20 months the developers may not send bugfix/PRs against 4.7 and expect future RMs to merge them forward as that would require both merge-conflict fixing and testing for all intermediate branches 4.8 to 4.20 (assuming, monthly releases we’ll at least reach 4.20 in 14-20 months and I’m not sure if RMs will have time and dedication to test all 12+ releases/branches ). For non-LTS branches, it may not make sense to even have those bugfixes.

In my experience (with pseudo LTS branches, 4.3/4.5) and opinion, LTS branches are going to diverge wrt master with time but they are going to have a dead-end.

About cherry-picking, the way we’re going git commits/merge at least I’m not able to follow the git history at all, it looks like a mess to me. We talk about ability to trace commits through branches, but I cannot even follow changes in the same branch now (say master). I personally use git diff and git log -p to trace changes using differences now (in files or paths/folders). Cherry-picking is not bad, if done right (always include the git commit ID from where it was picked using -x -s) you can trace it.

Regards.

[ShapeBlue]<http://www.shapeblue.com>
Rohit Yadav
Software Architect , ShapeBlue

d: | s: +44 203 603 0540<tel:|%20s:%20+44%20203%20603%200540> | m: +91 8826230892<tel:+91%208826230892>

e: rohit.yadav@shapeblue.com | t: <mailto:rohit.yadav@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com>

a: 53 Chandos Place, Covent Garden London WC2N 4HS UK

[cid:image608ca6.png@adf34d27.428e2635]

Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by Daan Hoogland <da...@gmail.com>.

John, I really don't see any reason to allow backporting. We refuse new
features in LTS and with that have no excuse to backport anything any more.
Can you give an example to prove me wrong?

On Tue, Jan 19, 2016 at 10:01 PM, Paul Angus <pa...@shapeblue.com>
wrote:

> Hi Ilya (and all others),
>
> We (ShapeBlue) agree with you regarding the importance of automated
> integration testing. The consulting team are currently working to
> understand Marvin fully and what pieces we need to be able deploy properly
> representative (virtualised) infrastructures to test against. We intend to
> open source our resultant framework, with a view to community members being
> able to use it themselves in their own labs but also so that as a community
> we can build it out somewhere to be used as part of the projects' testing
> regime.
>
> We'll be reaching out to the community soon to work on the failures we're
> seeing currently and understand where they come from - ie Marvin build, the
> environment, the tests or CloudStack (watch out Mike T - I'm about to watch
> your presentation video).
>
> We see this an important initiative for CloudStack as a whole, agile or
> otherwise. But ultimately this is 'only' regression testing and the
> organisations which need/want LTS, require it for a number of reasons,
> including the fact new features bring new bugs which, if we knew we had to
> test for, probably wouldn't have been there in the first place.
>
>
>
> Paul Angus
> VP Technology   ,       ShapeBlue
>
>
> t:      @cloudyangus<te...@cloudyangus>
>
> e:      paul.angus@shapeblue.com<ma...@shapeblue.com>
> |      w:      www.shapeblue.com<http://www.shapeblue.com>
>
>
>
>
>
> -----Original Message-----
> From: ilya [mailto:ilya.mailing.lists@gmail.com]
> Sent: Tuesday, January 19, 2016 6:39 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] LTS Release Cycle
>
> > Therefore, the process should strive to make as a few releases as
> necessary to achieve this goal.
>
> I guess part two to this question would be - we need the automated testing
> environments. This can ensure rapid release testing and acutal release, and
> we dont have to restrains ourselves to limited number of releases LTS
> release due to QA pains.
>
> We need a separate initiative with CloudStack testing framework.
>
> On 1/18/16 6:54 PM, John Burwell wrote:
> > Ilya,
> >
> > Unless we have a bug fix that addresses a significant, widespread system
> stability problem or a high priority/impact security issue, an LTS will
> roll up a number of fixes. Each release would receive the full system test
> to verify that the patch set does not introduce regression defects. I
> believe that most LTS users want a few releases as necessary to keep their
> systems up-to-date and stable because each upgrade carries operational risk
> and downtime. Therefore, the process should strive to make as a few
> releases as necessary to achieve this goal.
> >
> > Thanks,
> > -John
> >
> >> On Jan 15, 2016, at 3:22 PM, ilya <il...@gmail.com> wrote:
> >>
> >> John
> >>
> >> Thank you for taking time writing out the LTS proposal.
> >>
> >>> Broad community support is vital to guarantee the twenty (20) month
> >>> support period for each LTS branch. Given the ebbs and flows of
> >>> contribution and committer priorities, ShapeBlue will provide a
> >>> release manager, as well as, engineering support to fill any
> >>> contribution gaps to ensure that the community fulfills LTS
> commitments.
> >>
> >> You guys rock!!
> >>
> >> I'm +1 on this,
> >>
> >> Can you please expand on the QA side of LTS. Since this is more
> >> around long term bug/security fix - i'd think - the testing will be
> >> minimal, to the scope that fix applies - which will speed up the
> >> release process in general. What are your thoughts on this?
> >>
> >>
> >> Thanks
> >> ilya
> >>
> >>
> >>
> >>
> >>
> >> On 1/15/16 10:48 AM, John Burwell wrote:
> >>> Motivation
> >>> ========
> >>>
> >>> The current monthly release cycle addresses the needs of users
> >>> focused on deploying new functionality as quickly as possible. It
> >>> does not address the needs of users oriented towards stability
> >>> rather than new functionality. These users typically employ QA
> >>> processes to comply with corporate policy and/or regulatory
> >>> requirements. To maintain a growing, thriving community, we must
> address the needs of both user types.
> >>> Therefore, I propose that we overlay a LTS release cycle onto the
> >>> monthly release cycle to address the needs of stability-oriented
> >>> users with minimal to no impact on the monthly release cycle. This
> >>> proposed LTS release cycle has the following goals:
> >>>
> >>> * Prefer Stability to New Functionality: Deliver releases that only
> >>> address defects and CVEs. This narrowly focused change scope greatly
> >>> reduces the upgrade risk/operational impact and shorter internal QA
> cycles.
> >>> * Reliable Release Lifetimes: Embracing a time-based release
> >>> strategy, the LTS release cycle will provide users with a reliable
> >>> support time frames. Users can use these time frames provide users
> >>> with an 20 month window in which to plan upgrades.
> >>> * Support Sustainability: With a defined end of support for LTS
> >>> releases and a maximum of two (2) LTS releases under active
> >>> maintenance at any given time, community members can better plan
> >>> their commitments to release support activities. We also have a
> >>> agreed upon policy for release end-of-life (EOL) to debate about
> continuing work on old releases.
> >>>
> >>> Proposed Process
> >>> ==============
> >>>
> >>> LTS release branches will be cut twice year on 1 Jan and 1 July from
> >>> the tag of the most recent monthly release. The branch will be named
> >>> <base
> >>> version>-LTS and each LTS release will be versioned in the form of
> >>> version><base -<LTS revision number>. For example, if we cut an LTS
> >>> version>branch
> >>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version
> >>> of the first LTS release would be 4.7.0-0, the second would be
> >>> 4.7.0-1, etc. This release naming convention differentiates LTS and
> >>> monthly releases, communicates the version on which the LTS release
> >>> is based, and allows the maintenance releases for monthly releases
> >>> without version number contention/conflict. Finally, like master, an
> >>> LTS branch would be always deployable following its initial release.
> >>> While it is unlikely that LTS users would deploy from the branch,
> >>> the quality discipline of this requirement will benefit the long term
> stability of LTS releases.
> >>> All PRs targeting an LTS would require two LGTMs in order to be merged.
> >>>
> >>> The following are the types of changes that would permitted and
> >>> guarantees provided to users:
> >>>
> >>> * No features or enhancements would be backported to LTS release
> branches.
> >>> * Database changes would be limited to those required to address the
> >>> backported defect fixes.
> >>> * Support for the release/version of the following components from
> >>> the release on which the LTS is based throughout the entire release
> cycle:
> >>> * MySQL/MariaDB
> >>> * JDK/JRE
> >>> * Linux distributions
> >>> * API compatibility for between all LTS revisions. API changes would
> >>> be limited to those required to fix defects or address security issues.
> >>>
> >>> An LTS release would have a twenty (20) month lifetime from the date
> >>> the release branch is cut. This support period allows up to two (2)
> >>> months of branch stabilization before initial release with a minimum
> >>> of eighteen (18) months of availability for deployment. LTS releases
> >>> would have the following support periods:
> >>>
> >>> * 0-14 months: backport all defect fixes in the scope of the LTS
> >>> release functionality; fix all blocker and critical priority defects
> >>> identified in the branch
> >>> * 14-20 months: backport only CVE fixes in the scope of the LTS
> >>> release functionality; fix all blocker priority defects in the
> >>> branch
> >>>
> >>> Defect fixes that originate in an LTS branch will be pulled forward
> >>> to master only. Finally, an LTS branch should be release the fewest
> >>> times necessary to deliver fixes in a relatively timely manner.
> >>> Therefore, LTS releases will be triggered based on the number of
> >>> pending of fixes and their severity with no defect fix awaiting
> >>> release more than forty-five
> >>> (45) days. CVE fixes would trigger an immediate release of an LTS
> branch.
> >>>
> >>> Resourcing and Proposed Timeline
> >>> ===========================
> >>>
> >>> Broad community support is vital to guarantee the twenty (20) month
> >>> support period for each LTS branch. Given the ebbs and flows of
> >>> contribution and committer priorities, ShapeBlue will provide a
> >>> release manager, as well as, engineering support to fill any
> >>> contribution gaps to ensure that the community fulfills LTS
> commitments.
> >>>
> >>> In order to prepare for supporting LTS releases, we would need to
> >>> complete the following items:
> >>>
> >>> 1. All tools that do version number comparisons would be made aware
> >>> of the LTS versioning scheme 2. Officially support running the
> >>> management server on Java 8 since Java
> >>> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the
> >>> Java
> >>> 1.8 compiler and run on Java 1.8). Providing a 20-month support
> >>> window on an EOL JVM is an unacceptable security risk.
> >>> 3. Update the wiki and website to explain the new release cycle and
> >>> help users decide which release type suits their needs 4. Define an
> >>> initial test plan for LTS stabilization 5. Agree on the definitions
> >>> of ticket severities
> >>>
> >>> In order to address these items and start on a regular rhythm, I
> >>> propose that first LTS cycle begin on 1 July 2015. In the interim,
> >>> we would continue to ship critical bug fixes from the 4.5 release as
> >>> this release seems to be the most commonly deployed in the community.
> >>>
> >>> Together, the monthly and LTS release cycles address the needs of
> >>> the entire Apache CloudStack user community. I believe that the
> >>> process described in the proposal will yield releases that meet the
> >>> needs of users requiring release stability without adversely
> >>> affecting the velocity of the monthly release cycle.
> >>>
> >>> Thanks,
> >>> -John
> >>>
> >>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
> >>>
> >>>
> >>> ShapeBlue <http://www.shapeblue.com> John Burwell ShapeBlue
> >>>
> >>> d: *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
> >>> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
> >>>
> >>> e: *john.burwell@shapeblue.com | t: *
> >>> <mailto:john.burwell@shapeblue.com%20|%20t:> | w:
> >>> *www.shapeblue.com* <http://www.shapeblue.com>
> >>>
> >>> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
> >>>
> >>> Shape Blue Ltd is a company incorporated in England & Wales.
> >>> ShapeBlue Services India LLP is a company incorporated in India and
> >>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
> >>> Consultoria Ltda is a company incorporated in Brasil and is operated
> >>> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
> >>> registered by The Republic of South Africa and is traded under
> >>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
> >>> This email and any attachments to it may be confidential and are
> >>> intended solely for the use of the individual to whom it is addressed.
> >>> Any views or opinions expressed are solely those of the author and
> >>> do not necessarily represent those of Shape Blue Ltd or related
> companies.
> >>> If you are not the intended recipient of this email, you must
> >>> neither take any action based upon its contents, nor copy or show it
> to anyone.
> >>> Please contact the sender if you believe you have received this
> >>> email in error.
> >>>
> >>>
> >>> Find out more about ShapeBlue and our range of CloudStack related
> services:
> >>> IaaS Cloud Design & Build
> >>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
> >>> rapid IaaS deployment framework <http://shapeblue.com/csforge/>
> >>> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/>
> >>> | CloudStack Software Engineering
> >>> <http://shapeblue.com/cloudstack-software-engineering/>
> >>> CloudStack Infrastructure Support
> >>> <http://shapeblue.com/cloudstack-infrastructure-support/> |
> >>> CloudStack Bootcamp Training Courses
> >>> <http://shapeblue.com/cloudstack-training/>
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services:
> > IaaS Cloud Design &
> > Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
> > rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
> > CloudStack Software
> > Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> > CloudStack Infrastructure
> > Support<http://shapeblue.com/cloudstack-infrastructure-support/> |
> > CloudStack Bootcamp Training
> > Courses<http://shapeblue.com/cloudstack-training/>
> >
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
> IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
> CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>



-- 
Daan

RE: [PROPOSAL] LTS Release Cycle

Posted by Paul Angus <pa...@shapeblue.com>.

Absolutely Remi, we're looking to learn all that we can from those who already use Marvin. It's tougher for us non-developers to get started, but once we get the understanding in terms which we are used to working with, then we can better explain it to users and expand the number of people who can carry out testing.




Paul Angus
VP Technology   ,       ShapeBlue


t:      @cloudyangus<te...@cloudyangus>

e:      paul.angus@shapeblue.com<ma...@shapeblue.com>        |      w:      www.shapeblue.com<http://www.shapeblue.com>





-----Original Message-----
From: Remi Bergsma [mailto:RBergsma@schubergphilis.com]
Sent: 20 January 2016 10:48
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] LTS Release Cycle

Hi Paul,

I just hope you won’t reinvent the wheel ;-) Feel free to use what was build to test the 500+ PRs that got merged over the last couple of months to build 4.6, 4.7 and 4.8. For results see the comments in all these PRs.



More info:
https://github.com/schubergphilis/MCT-shared

This is already being used by PCExtreme, Leaseweb and Schuberg Philis.

Regards,
Remi


On 19/01/16 22:01, "Paul Angus" <pa...@shapeblue.com> wrote:

>Hi Ilya (and all others),
>
>We (ShapeBlue) agree with you regarding the importance of automated integration testing. The consulting team are currently working to understand Marvin fully and what pieces we need to be able deploy properly representative (virtualised) infrastructures to test against. We intend to open source our resultant framework, with a view to community members being able to use it themselves in their own labs but also so that as a community we can build it out somewhere to be used as part of the projects' testing regime.
>
>We'll be reaching out to the community soon to work on the failures we're seeing currently and understand where they come from - ie Marvin build, the environment, the tests or CloudStack (watch out Mike T - I'm about to watch your presentation video).
>
>We see this an important initiative for CloudStack as a whole, agile or otherwise. But ultimately this is 'only' regression testing and the organisations which need/want LTS, require it for a number of reasons, including the fact new features bring new bugs which, if we knew we had to test for, probably wouldn't have been there in the first place.
>
>
>
>Paul Angus
>VP Technology , ShapeBlue
>
>
>t: @cloudyangus<te...@cloudyangus>
>
>e: paul.angus@shapeblue.com<ma...@shapeblue.com> | w: www.shapeblue.com<http://www.shapeblue.com>
>
>
>
>
>
>-----Original Message-----
>From: ilya [mailto:ilya.mailing.lists@gmail.com]
>Sent: Tuesday, January 19, 2016 6:39 PM
>To: dev@cloudstack.apache.org
>Subject: Re: [PROPOSAL] LTS Release Cycle
>
>> Therefore, the process should strive to make as a few releases as
>necessary to achieve this goal.
>
>I guess part two to this question would be - we need the automated testing environments. This can ensure rapid release testing and acutal release, and we dont have to restrains ourselves to limited number of releases LTS release due to QA pains.
>
>We need a separate initiative with CloudStack testing framework.
>
>On 1/18/16 6:54 PM, John Burwell wrote:
>> Ilya,
>>
>> Unless we have a bug fix that addresses a significant, widespread system stability problem or a high priority/impact security issue, an LTS will roll up a number of fixes. Each release would receive the full system test to verify that the patch set does not introduce regression defects. I believe that most LTS users want a few releases as necessary to keep their systems up-to-date and stable because each upgrade carries operational risk and downtime. Therefore, the process should strive to make as a few releases as necessary to achieve this goal.
>>
>> Thanks,
>> -John
>>
>>> On Jan 15, 2016, at 3:22 PM, ilya <il...@gmail.com> wrote:
>>>
>>> John
>>>
>>> Thank you for taking time writing out the LTS proposal.
>>>
>>>> Broad community support is vital to guarantee the twenty (20) month
>>>> support period for each LTS branch. Given the ebbs and flows of
>>>> contribution and committer priorities, ShapeBlue will provide a
>>>> release manager, as well as, engineering support to fill any
>>>> contribution gaps to ensure that the community fulfills LTS commitments.
>>>
>>> You guys rock!!
>>>
>>> I'm +1 on this,
>>>
>>> Can you please expand on the QA side of LTS. Since this is more
>>> around long term bug/security fix - i'd think - the testing will be
>>> minimal, to the scope that fix applies - which will speed up the
>>> release process in general. What are your thoughts on this?
>>>
>>>
>>> Thanks
>>> ilya
>>>
>>>
>>>
>>>
>>>
>>> On 1/15/16 10:48 AM, John Burwell wrote:
>>>> Motivation
>>>> ========
>>>>
>>>> The current monthly release cycle addresses the needs of users
>>>> focused on deploying new functionality as quickly as possible. It
>>>> does not address the needs of users oriented towards stability
>>>> rather than new functionality. These users typically employ QA
>>>> processes to comply with corporate policy and/or regulatory
>>>> requirements. To maintain a growing, thriving community, we must address the needs of both user types.
>>>> Therefore, I propose that we overlay a LTS release cycle onto the
>>>> monthly release cycle to address the needs of stability-oriented
>>>> users with minimal to no impact on the monthly release cycle. This
>>>> proposed LTS release cycle has the following goals:
>>>>
>>>> * Prefer Stability to New Functionality: Deliver releases that only
>>>> address defects and CVEs. This narrowly focused change scope
>>>> greatly reduces the upgrade risk/operational impact and shorter internal QA cycles.
>>>> * Reliable Release Lifetimes: Embracing a time-based release
>>>> strategy, the LTS release cycle will provide users with a reliable
>>>> support time frames. Users can use these time frames provide users
>>>> with an 20 month window in which to plan upgrades.
>>>> * Support Sustainability: With a defined end of support for LTS
>>>> releases and a maximum of two (2) LTS releases under active
>>>> maintenance at any given time, community members can better plan
>>>> their commitments to release support activities. We also have a
>>>> agreed upon policy for release end-of-life (EOL) to debate about continuing work on old releases.
>>>>
>>>> Proposed Process
>>>> ==============
>>>>
>>>> LTS release branches will be cut twice year on 1 Jan and 1 July
>>>> from the tag of the most recent monthly release. The branch will be
>>>> named <base
>>>> version>-LTS and each LTS release will be versioned in the form of
>>>> version><base -<LTS revision number>. For example, if we cut an LTS
>>>> version>branch
>>>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version
>>>> of the first LTS release would be 4.7.0-0, the second would be
>>>> 4.7.0-1, etc. This release naming convention differentiates LTS and
>>>> monthly releases, communicates the version on which the LTS release
>>>> is based, and allows the maintenance releases for monthly releases
>>>> without version number contention/conflict. Finally, like master,
>>>> an LTS branch would be always deployable following its initial release.
>>>> While it is unlikely that LTS users would deploy from the branch,
>>>> the quality discipline of this requirement will benefit the long term stability of LTS releases.
>>>> All PRs targeting an LTS would require two LGTMs in order to be merged.
>>>>
>>>> The following are the types of changes that would permitted and
>>>> guarantees provided to users:
>>>>
>>>> * No features or enhancements would be backported to LTS release branches.
>>>> * Database changes would be limited to those required to address
>>>> the backported defect fixes.
>>>> * Support for the release/version of the following components from
>>>> the release on which the LTS is based throughout the entire release cycle:
>>>> * MySQL/MariaDB
>>>> * JDK/JRE
>>>> * Linux distributions
>>>> * API compatibility for between all LTS revisions. API changes
>>>> would be limited to those required to fix defects or address security issues.
>>>>
>>>> An LTS release would have a twenty (20) month lifetime from the
>>>> date the release branch is cut. This support period allows up to
>>>> two (2) months of branch stabilization before initial release with
>>>> a minimum of eighteen (18) months of availability for deployment.
>>>> LTS releases would have the following support periods:
>>>>
>>>> * 0-14 months: backport all defect fixes in the scope of the LTS
>>>> release functionality; fix all blocker and critical priority
>>>> defects identified in the branch
>>>> * 14-20 months: backport only CVE fixes in the scope of the LTS
>>>> release functionality; fix all blocker priority defects in the
>>>> branch
>>>>
>>>> Defect fixes that originate in an LTS branch will be pulled forward
>>>> to master only. Finally, an LTS branch should be release the fewest
>>>> times necessary to deliver fixes in a relatively timely manner.
>>>> Therefore, LTS releases will be triggered based on the number of
>>>> pending of fixes and their severity with no defect fix awaiting
>>>> release more than forty-five
>>>> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>>>>
>>>> Resourcing and Proposed Timeline
>>>> ===========================
>>>>
>>>> Broad community support is vital to guarantee the twenty (20) month
>>>> support period for each LTS branch. Given the ebbs and flows of
>>>> contribution and committer priorities, ShapeBlue will provide a
>>>> release manager, as well as, engineering support to fill any
>>>> contribution gaps to ensure that the community fulfills LTS commitments.
>>>>
>>>> In order to prepare for supporting LTS releases, we would need to
>>>> complete the following items:
>>>>
>>>> 1. All tools that do version number comparisons would be made aware
>>>> of the LTS versioning scheme 2. Officially support running the
>>>> management server on Java 8 since Java
>>>> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the
>>>> Java
>>>> 1.8 compiler and run on Java 1.8). Providing a 20-month support
>>>> window on an EOL JVM is an unacceptable security risk.
>>>> 3. Update the wiki and website to explain the new release cycle and
>>>> help users decide which release type suits their needs 4. Define an
>>>> initial test plan for LTS stabilization 5. Agree on the definitions
>>>> of ticket severities
>>>>
>>>> In order to address these items and start on a regular rhythm, I
>>>> propose that first LTS cycle begin on 1 July 2015. In the interim,
>>>> we would continue to ship critical bug fixes from the 4.5 release
>>>> as this release seems to be the most commonly deployed in the community.
>>>>
>>>> Together, the monthly and LTS release cycles address the needs of
>>>> the entire Apache CloudStack user community. I believe that the
>>>> process described in the proposal will yield releases that meet the
>>>> needs of users requiring release stability without adversely
>>>> affecting the velocity of the monthly release cycle.
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
>>>>
>>>>
>>>> ShapeBlue <http://www.shapeblue.com> John Burwell ShapeBlue
>>>>
>>>> d: *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
>>>> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
>>>>
>>>> e: *john.burwell@shapeblue.com | t: *
>>>> <mailto:john.burwell@shapeblue.com%20|%20t:> | w:
>>>> *www.shapeblue.com* <http://www.shapeblue.com>
>>>>
>>>> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
>>>>
>>>> Shape Blue Ltd is a company incorporated in England & Wales.
>>>> ShapeBlue Services India LLP is a company incorporated in India and
>>>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
>>>> Consultoria Ltda is a company incorporated in Brasil and is
>>>> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
>>>> a company registered by The Republic of South Africa and is traded
>>>> under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>>> This email and any attachments to it may be confidential and are
>>>> intended solely for the use of the individual to whom it is addressed.
>>>> Any views or opinions expressed are solely those of the author and
>>>> do not necessarily represent those of Shape Blue Ltd or related companies.
>>>> If you are not the intended recipient of this email, you must
>>>> neither take any action based upon its contents, nor copy or show it to anyone.
>>>> Please contact the sender if you believe you have received this
>>>> email in error.
>>>>
>>>>
>>>> Find out more about ShapeBlue and our range of CloudStack related services:
>>>> IaaS Cloud Design & Build
>>>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
>>>> rapid IaaS deployment framework <http://shapeblue.com/csforge/>
>>>> CloudStack Consulting
>>>> <http://shapeblue.com/cloudstack-consultancy/>
>>>> | CloudStack Software Engineering
>>>> <http://shapeblue.com/cloudstack-software-engineering/>
>>>> CloudStack Infrastructure Support
>>>> <http://shapeblue.com/cloudstack-infrastructure-support/> |
>>>> CloudStack Bootcamp Training Courses
>>>> <http://shapeblue.com/cloudstack-training/>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services:
>> IaaS Cloud Design &
>> Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
>> rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
>> CloudStack Software
>> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>> CloudStack Infrastructure
>> Support<http://shapeblue.com/cloudstack-infrastructure-support/> |
>> CloudStack Bootcamp Training
>> Courses<http://shapeblue.com/cloudstack-training/>
>>
>Find out more about ShapeBlue and our range of CloudStack related services:
>IaaS Cloud Design &
>Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
>rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
>CloudStack Software
>Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>CloudStack Infrastructure
>Support<http://shapeblue.com/cloudstack-infrastructure-support/> |
>CloudStack Bootcamp Training
>Courses<http://shapeblue.com/cloudstack-training/>
Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by Remi Bergsma <RB...@schubergphilis.com>.

Hi Paul,

I just hope you won’t reinvent the wheel ;-) Feel free to use what was build to test the 500+ PRs that got merged over the last couple of months to build 4.6, 4.7 and 4.8. For results see the comments in all these PRs.



More info:
https://github.com/schubergphilis/MCT-shared

This is already being used by PCExtreme, Leaseweb and Schuberg Philis.

Regards,
Remi


On 19/01/16 22:01, "Paul Angus" <pa...@shapeblue.com> wrote:

>Hi Ilya (and all others),
>
>We (ShapeBlue) agree with you regarding the importance of automated integration testing. The consulting team are currently working to understand Marvin fully and what pieces we need to be able deploy properly representative (virtualised) infrastructures to test against. We intend to open source our resultant framework, with a view to community members being able to use it themselves in their own labs but also so that as a community we can build it out somewhere to be used as part of the projects' testing regime.
>
>We'll be reaching out to the community soon to work on the failures we're seeing currently and understand where they come from - ie Marvin build, the environment, the tests or CloudStack (watch out Mike T - I'm about to watch your presentation video).
>
>We see this an important initiative for CloudStack as a whole, agile or otherwise. But ultimately this is 'only' regression testing and the organisations which need/want LTS, require it for a number of reasons, including the fact new features bring new bugs which, if we knew we had to test for, probably wouldn't have been there in the first place.
>
>
>
>Paul Angus
>VP Technology   ,       ShapeBlue
>
>
>t:      @cloudyangus<te...@cloudyangus>
>
>e:      paul.angus@shapeblue.com<ma...@shapeblue.com>        |      w:      www.shapeblue.com<http://www.shapeblue.com>
>
>
>
>
>
>-----Original Message-----
>From: ilya [mailto:ilya.mailing.lists@gmail.com]
>Sent: Tuesday, January 19, 2016 6:39 PM
>To: dev@cloudstack.apache.org
>Subject: Re: [PROPOSAL] LTS Release Cycle
>
>> Therefore, the process should strive to make as a few releases as
>necessary to achieve this goal.
>
>I guess part two to this question would be - we need the automated testing environments. This can ensure rapid release testing and acutal release, and we dont have to restrains ourselves to limited number of releases LTS release due to QA pains.
>
>We need a separate initiative with CloudStack testing framework.
>
>On 1/18/16 6:54 PM, John Burwell wrote:
>> Ilya,
>>
>> Unless we have a bug fix that addresses a significant, widespread system stability problem or a high priority/impact security issue, an LTS will roll up a number of fixes. Each release would receive the full system test to verify that the patch set does not introduce regression defects. I believe that most LTS users want a few releases as necessary to keep their systems up-to-date and stable because each upgrade carries operational risk and downtime. Therefore, the process should strive to make as a few releases as necessary to achieve this goal.
>>
>> Thanks,
>> -John
>>
>>> On Jan 15, 2016, at 3:22 PM, ilya <il...@gmail.com> wrote:
>>>
>>> John
>>>
>>> Thank you for taking time writing out the LTS proposal.
>>>
>>>> Broad community support is vital to guarantee the twenty (20) month
>>>> support period for each LTS branch. Given the ebbs and flows of
>>>> contribution and committer priorities, ShapeBlue will provide a
>>>> release manager, as well as, engineering support to fill any
>>>> contribution gaps to ensure that the community fulfills LTS commitments.
>>>
>>> You guys rock!!
>>>
>>> I'm +1 on this,
>>>
>>> Can you please expand on the QA side of LTS. Since this is more
>>> around long term bug/security fix - i'd think - the testing will be
>>> minimal, to the scope that fix applies - which will speed up the
>>> release process in general. What are your thoughts on this?
>>>
>>>
>>> Thanks
>>> ilya
>>>
>>>
>>>
>>>
>>>
>>> On 1/15/16 10:48 AM, John Burwell wrote:
>>>> Motivation
>>>> ========
>>>>
>>>> The current monthly release cycle addresses the needs of users
>>>> focused on deploying new functionality as quickly as possible. It
>>>> does not address the needs of users oriented towards stability
>>>> rather than new functionality. These users typically employ QA
>>>> processes to comply with corporate policy and/or regulatory
>>>> requirements. To maintain a growing, thriving community, we must address the needs of both user types.
>>>> Therefore, I propose that we overlay a LTS release cycle onto the
>>>> monthly release cycle to address the needs of stability-oriented
>>>> users with minimal to no impact on the monthly release cycle. This
>>>> proposed LTS release cycle has the following goals:
>>>>
>>>> * Prefer Stability to New Functionality: Deliver releases that only
>>>> address defects and CVEs. This narrowly focused change scope greatly
>>>> reduces the upgrade risk/operational impact and shorter internal QA cycles.
>>>> * Reliable Release Lifetimes: Embracing a time-based release
>>>> strategy, the LTS release cycle will provide users with a reliable
>>>> support time frames. Users can use these time frames provide users
>>>> with an 20 month window in which to plan upgrades.
>>>> * Support Sustainability: With a defined end of support for LTS
>>>> releases and a maximum of two (2) LTS releases under active
>>>> maintenance at any given time, community members can better plan
>>>> their commitments to release support activities. We also have a
>>>> agreed upon policy for release end-of-life (EOL) to debate about continuing work on old releases.
>>>>
>>>> Proposed Process
>>>> ==============
>>>>
>>>> LTS release branches will be cut twice year on 1 Jan and 1 July from
>>>> the tag of the most recent monthly release. The branch will be named
>>>> <base
>>>> version>-LTS and each LTS release will be versioned in the form of
>>>> version><base -<LTS revision number>. For example, if we cut an LTS
>>>> version>branch
>>>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version
>>>> of the first LTS release would be 4.7.0-0, the second would be
>>>> 4.7.0-1, etc. This release naming convention differentiates LTS and
>>>> monthly releases, communicates the version on which the LTS release
>>>> is based, and allows the maintenance releases for monthly releases
>>>> without version number contention/conflict. Finally, like master, an
>>>> LTS branch would be always deployable following its initial release.
>>>> While it is unlikely that LTS users would deploy from the branch,
>>>> the quality discipline of this requirement will benefit the long term stability of LTS releases.
>>>> All PRs targeting an LTS would require two LGTMs in order to be merged.
>>>>
>>>> The following are the types of changes that would permitted and
>>>> guarantees provided to users:
>>>>
>>>> * No features or enhancements would be backported to LTS release branches.
>>>> * Database changes would be limited to those required to address the
>>>> backported defect fixes.
>>>> * Support for the release/version of the following components from
>>>> the release on which the LTS is based throughout the entire release cycle:
>>>> * MySQL/MariaDB
>>>> * JDK/JRE
>>>> * Linux distributions
>>>> * API compatibility for between all LTS revisions. API changes would
>>>> be limited to those required to fix defects or address security issues.
>>>>
>>>> An LTS release would have a twenty (20) month lifetime from the date
>>>> the release branch is cut. This support period allows up to two (2)
>>>> months of branch stabilization before initial release with a minimum
>>>> of eighteen (18) months of availability for deployment. LTS releases
>>>> would have the following support periods:
>>>>
>>>> * 0-14 months: backport all defect fixes in the scope of the LTS
>>>> release functionality; fix all blocker and critical priority defects
>>>> identified in the branch
>>>> * 14-20 months: backport only CVE fixes in the scope of the LTS
>>>> release functionality; fix all blocker priority defects in the
>>>> branch
>>>>
>>>> Defect fixes that originate in an LTS branch will be pulled forward
>>>> to master only. Finally, an LTS branch should be release the fewest
>>>> times necessary to deliver fixes in a relatively timely manner.
>>>> Therefore, LTS releases will be triggered based on the number of
>>>> pending of fixes and their severity with no defect fix awaiting
>>>> release more than forty-five
>>>> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>>>>
>>>> Resourcing and Proposed Timeline
>>>> ===========================
>>>>
>>>> Broad community support is vital to guarantee the twenty (20) month
>>>> support period for each LTS branch. Given the ebbs and flows of
>>>> contribution and committer priorities, ShapeBlue will provide a
>>>> release manager, as well as, engineering support to fill any
>>>> contribution gaps to ensure that the community fulfills LTS commitments.
>>>>
>>>> In order to prepare for supporting LTS releases, we would need to
>>>> complete the following items:
>>>>
>>>> 1. All tools that do version number comparisons would be made aware
>>>> of the LTS versioning scheme 2. Officially support running the
>>>> management server on Java 8 since Java
>>>> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the
>>>> Java
>>>> 1.8 compiler and run on Java 1.8). Providing a 20-month support
>>>> window on an EOL JVM is an unacceptable security risk.
>>>> 3. Update the wiki and website to explain the new release cycle and
>>>> help users decide which release type suits their needs 4. Define an
>>>> initial test plan for LTS stabilization 5. Agree on the definitions
>>>> of ticket severities
>>>>
>>>> In order to address these items and start on a regular rhythm, I
>>>> propose that first LTS cycle begin on 1 July 2015. In the interim,
>>>> we would continue to ship critical bug fixes from the 4.5 release as
>>>> this release seems to be the most commonly deployed in the community.
>>>>
>>>> Together, the monthly and LTS release cycles address the needs of
>>>> the entire Apache CloudStack user community. I believe that the
>>>> process described in the proposal will yield releases that meet the
>>>> needs of users requiring release stability without adversely
>>>> affecting the velocity of the monthly release cycle.
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
>>>>
>>>>
>>>> ShapeBlue <http://www.shapeblue.com> John Burwell ShapeBlue
>>>>
>>>> d: *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
>>>> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
>>>>
>>>> e: *john.burwell@shapeblue.com | t: *
>>>> <mailto:john.burwell@shapeblue.com%20|%20t:> | w:
>>>> *www.shapeblue.com* <http://www.shapeblue.com>
>>>>
>>>> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
>>>>
>>>> Shape Blue Ltd is a company incorporated in England & Wales.
>>>> ShapeBlue Services India LLP is a company incorporated in India and
>>>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
>>>> Consultoria Ltda is a company incorporated in Brasil and is operated
>>>> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
>>>> registered by The Republic of South Africa and is traded under
>>>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>>> This email and any attachments to it may be confidential and are
>>>> intended solely for the use of the individual to whom it is addressed.
>>>> Any views or opinions expressed are solely those of the author and
>>>> do not necessarily represent those of Shape Blue Ltd or related companies.
>>>> If you are not the intended recipient of this email, you must
>>>> neither take any action based upon its contents, nor copy or show it to anyone.
>>>> Please contact the sender if you believe you have received this
>>>> email in error.
>>>>
>>>>
>>>> Find out more about ShapeBlue and our range of CloudStack related services:
>>>> IaaS Cloud Design & Build
>>>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
>>>> rapid IaaS deployment framework <http://shapeblue.com/csforge/>
>>>> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/>
>>>> | CloudStack Software Engineering
>>>> <http://shapeblue.com/cloudstack-software-engineering/>
>>>> CloudStack Infrastructure Support
>>>> <http://shapeblue.com/cloudstack-infrastructure-support/> |
>>>> CloudStack Bootcamp Training Courses
>>>> <http://shapeblue.com/cloudstack-training/>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services:
>> IaaS Cloud Design &
>> Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
>> rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
>> CloudStack Software
>> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>> CloudStack Infrastructure
>> Support<http://shapeblue.com/cloudstack-infrastructure-support/> |
>> CloudStack Bootcamp Training
>> Courses<http://shapeblue.com/cloudstack-training/>
>>
>Find out more about ShapeBlue and our range of CloudStack related services:
>IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

RE: [PROPOSAL] LTS Release Cycle

Posted by Paul Angus <pa...@shapeblue.com>.

Hi Ilya (and all others),

We (ShapeBlue) agree with you regarding the importance of automated integration testing. The consulting team are currently working to understand Marvin fully and what pieces we need to be able deploy properly representative (virtualised) infrastructures to test against. We intend to open source our resultant framework, with a view to community members being able to use it themselves in their own labs but also so that as a community we can build it out somewhere to be used as part of the projects' testing regime.

We'll be reaching out to the community soon to work on the failures we're seeing currently and understand where they come from - ie Marvin build, the environment, the tests or CloudStack (watch out Mike T - I'm about to watch your presentation video).

We see this an important initiative for CloudStack as a whole, agile or otherwise. But ultimately this is 'only' regression testing and the organisations which need/want LTS, require it for a number of reasons, including the fact new features bring new bugs which, if we knew we had to test for, probably wouldn't have been there in the first place.



Paul Angus
VP Technology   ,       ShapeBlue


t:      @cloudyangus<te...@cloudyangus>

e:      paul.angus@shapeblue.com<ma...@shapeblue.com>        |      w:      www.shapeblue.com<http://www.shapeblue.com>





-----Original Message-----
From: ilya [mailto:ilya.mailing.lists@gmail.com]
Sent: Tuesday, January 19, 2016 6:39 PM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] LTS Release Cycle

> Therefore, the process should strive to make as a few releases as
necessary to achieve this goal.

I guess part two to this question would be - we need the automated testing environments. This can ensure rapid release testing and acutal release, and we dont have to restrains ourselves to limited number of releases LTS release due to QA pains.

We need a separate initiative with CloudStack testing framework.

On 1/18/16 6:54 PM, John Burwell wrote:
> Ilya,
>
> Unless we have a bug fix that addresses a significant, widespread system stability problem or a high priority/impact security issue, an LTS will roll up a number of fixes. Each release would receive the full system test to verify that the patch set does not introduce regression defects. I believe that most LTS users want a few releases as necessary to keep their systems up-to-date and stable because each upgrade carries operational risk and downtime. Therefore, the process should strive to make as a few releases as necessary to achieve this goal.
>
> Thanks,
> -John
>
>> On Jan 15, 2016, at 3:22 PM, ilya <il...@gmail.com> wrote:
>>
>> John
>>
>> Thank you for taking time writing out the LTS proposal.
>>
>>> Broad community support is vital to guarantee the twenty (20) month
>>> support period for each LTS branch. Given the ebbs and flows of
>>> contribution and committer priorities, ShapeBlue will provide a
>>> release manager, as well as, engineering support to fill any
>>> contribution gaps to ensure that the community fulfills LTS commitments.
>>
>> You guys rock!!
>>
>> I'm +1 on this,
>>
>> Can you please expand on the QA side of LTS. Since this is more
>> around long term bug/security fix - i'd think - the testing will be
>> minimal, to the scope that fix applies - which will speed up the
>> release process in general. What are your thoughts on this?
>>
>>
>> Thanks
>> ilya
>>
>>
>>
>>
>>
>> On 1/15/16 10:48 AM, John Burwell wrote:
>>> Motivation
>>> ========
>>>
>>> The current monthly release cycle addresses the needs of users
>>> focused on deploying new functionality as quickly as possible. It
>>> does not address the needs of users oriented towards stability
>>> rather than new functionality. These users typically employ QA
>>> processes to comply with corporate policy and/or regulatory
>>> requirements. To maintain a growing, thriving community, we must address the needs of both user types.
>>> Therefore, I propose that we overlay a LTS release cycle onto the
>>> monthly release cycle to address the needs of stability-oriented
>>> users with minimal to no impact on the monthly release cycle. This
>>> proposed LTS release cycle has the following goals:
>>>
>>> * Prefer Stability to New Functionality: Deliver releases that only
>>> address defects and CVEs. This narrowly focused change scope greatly
>>> reduces the upgrade risk/operational impact and shorter internal QA cycles.
>>> * Reliable Release Lifetimes: Embracing a time-based release
>>> strategy, the LTS release cycle will provide users with a reliable
>>> support time frames. Users can use these time frames provide users
>>> with an 20 month window in which to plan upgrades.
>>> * Support Sustainability: With a defined end of support for LTS
>>> releases and a maximum of two (2) LTS releases under active
>>> maintenance at any given time, community members can better plan
>>> their commitments to release support activities. We also have a
>>> agreed upon policy for release end-of-life (EOL) to debate about continuing work on old releases.
>>>
>>> Proposed Process
>>> ==============
>>>
>>> LTS release branches will be cut twice year on 1 Jan and 1 July from
>>> the tag of the most recent monthly release. The branch will be named
>>> <base
>>> version>-LTS and each LTS release will be versioned in the form of
>>> version><base -<LTS revision number>. For example, if we cut an LTS
>>> version>branch
>>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version
>>> of the first LTS release would be 4.7.0-0, the second would be
>>> 4.7.0-1, etc. This release naming convention differentiates LTS and
>>> monthly releases, communicates the version on which the LTS release
>>> is based, and allows the maintenance releases for monthly releases
>>> without version number contention/conflict. Finally, like master, an
>>> LTS branch would be always deployable following its initial release.
>>> While it is unlikely that LTS users would deploy from the branch,
>>> the quality discipline of this requirement will benefit the long term stability of LTS releases.
>>> All PRs targeting an LTS would require two LGTMs in order to be merged.
>>>
>>> The following are the types of changes that would permitted and
>>> guarantees provided to users:
>>>
>>> * No features or enhancements would be backported to LTS release branches.
>>> * Database changes would be limited to those required to address the
>>> backported defect fixes.
>>> * Support for the release/version of the following components from
>>> the release on which the LTS is based throughout the entire release cycle:
>>> * MySQL/MariaDB
>>> * JDK/JRE
>>> * Linux distributions
>>> * API compatibility for between all LTS revisions. API changes would
>>> be limited to those required to fix defects or address security issues.
>>>
>>> An LTS release would have a twenty (20) month lifetime from the date
>>> the release branch is cut. This support period allows up to two (2)
>>> months of branch stabilization before initial release with a minimum
>>> of eighteen (18) months of availability for deployment. LTS releases
>>> would have the following support periods:
>>>
>>> * 0-14 months: backport all defect fixes in the scope of the LTS
>>> release functionality; fix all blocker and critical priority defects
>>> identified in the branch
>>> * 14-20 months: backport only CVE fixes in the scope of the LTS
>>> release functionality; fix all blocker priority defects in the
>>> branch
>>>
>>> Defect fixes that originate in an LTS branch will be pulled forward
>>> to master only. Finally, an LTS branch should be release the fewest
>>> times necessary to deliver fixes in a relatively timely manner.
>>> Therefore, LTS releases will be triggered based on the number of
>>> pending of fixes and their severity with no defect fix awaiting
>>> release more than forty-five
>>> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>>>
>>> Resourcing and Proposed Timeline
>>> ===========================
>>>
>>> Broad community support is vital to guarantee the twenty (20) month
>>> support period for each LTS branch. Given the ebbs and flows of
>>> contribution and committer priorities, ShapeBlue will provide a
>>> release manager, as well as, engineering support to fill any
>>> contribution gaps to ensure that the community fulfills LTS commitments.
>>>
>>> In order to prepare for supporting LTS releases, we would need to
>>> complete the following items:
>>>
>>> 1. All tools that do version number comparisons would be made aware
>>> of the LTS versioning scheme 2. Officially support running the
>>> management server on Java 8 since Java
>>> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the
>>> Java
>>> 1.8 compiler and run on Java 1.8). Providing a 20-month support
>>> window on an EOL JVM is an unacceptable security risk.
>>> 3. Update the wiki and website to explain the new release cycle and
>>> help users decide which release type suits their needs 4. Define an
>>> initial test plan for LTS stabilization 5. Agree on the definitions
>>> of ticket severities
>>>
>>> In order to address these items and start on a regular rhythm, I
>>> propose that first LTS cycle begin on 1 July 2015. In the interim,
>>> we would continue to ship critical bug fixes from the 4.5 release as
>>> this release seems to be the most commonly deployed in the community.
>>>
>>> Together, the monthly and LTS release cycles address the needs of
>>> the entire Apache CloudStack user community. I believe that the
>>> process described in the proposal will yield releases that meet the
>>> needs of users requiring release stability without adversely
>>> affecting the velocity of the monthly release cycle.
>>>
>>> Thanks,
>>> -John
>>>
>>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
>>>
>>>
>>> ShapeBlue <http://www.shapeblue.com> John Burwell ShapeBlue
>>>
>>> d: *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
>>> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
>>>
>>> e: *john.burwell@shapeblue.com | t: *
>>> <mailto:john.burwell@shapeblue.com%20|%20t:> | w:
>>> *www.shapeblue.com* <http://www.shapeblue.com>
>>>
>>> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
>>>
>>> Shape Blue Ltd is a company incorporated in England & Wales.
>>> ShapeBlue Services India LLP is a company incorporated in India and
>>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
>>> Consultoria Ltda is a company incorporated in Brasil and is operated
>>> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
>>> registered by The Republic of South Africa and is traded under
>>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>> This email and any attachments to it may be confidential and are
>>> intended solely for the use of the individual to whom it is addressed.
>>> Any views or opinions expressed are solely those of the author and
>>> do not necessarily represent those of Shape Blue Ltd or related companies.
>>> If you are not the intended recipient of this email, you must
>>> neither take any action based upon its contents, nor copy or show it to anyone.
>>> Please contact the sender if you believe you have received this
>>> email in error.
>>>
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related services:
>>> IaaS Cloud Design & Build
>>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
>>> rapid IaaS deployment framework <http://shapeblue.com/csforge/>
>>> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/>
>>> | CloudStack Software Engineering
>>> <http://shapeblue.com/cloudstack-software-engineering/>
>>> CloudStack Infrastructure Support
>>> <http://shapeblue.com/cloudstack-infrastructure-support/> |
>>> CloudStack Bootcamp Training Courses
>>> <http://shapeblue.com/cloudstack-training/>
>
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design &
> Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
> rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
> CloudStack Software
> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure
> Support<http://shapeblue.com/cloudstack-infrastructure-support/> |
> CloudStack Bootcamp Training
> Courses<http://shapeblue.com/cloudstack-training/>
>
Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by ilya <il...@gmail.com>.

> Therefore, the process should strive to make as a few releases as
necessary to achieve this goal.

I guess part two to this question would be - we need the automated
testing environments. This can ensure rapid release testing and acutal
release, and we dont have to restrains ourselves to limited number of
releases LTS release due to QA pains.

We need a separate initiative with CloudStack testing framework.

On 1/18/16 6:54 PM, John Burwell wrote:
> Ilya,
> 
> Unless we have a bug fix that addresses a significant, widespread system stability problem or a high priority/impact security issue, an LTS will roll up a number of fixes.   Each release would receive the full system test to verify that the patch set does not introduce regression defects.  I believe that most LTS users want a few releases as necessary to keep their systems up-to-date and stable because each upgrade carries operational risk and downtime.  Therefore, the process should strive to make as a few releases as necessary to achieve this goal.
> 
> Thanks,
> -John
> 
>> On Jan 15, 2016, at 3:22 PM, ilya <il...@gmail.com> wrote:
>>
>> John
>>
>> Thank you for taking time writing out the LTS proposal.
>>
>>> Broad community support is vital to guarantee the twenty (20) month
>>> support period for each LTS branch. Given the ebbs and flows of
>>> contribution and committer priorities, ShapeBlue will provide a release
>>> manager, as well as, engineering support to fill any contribution gaps
>>> to ensure that the community fulfills LTS commitments.
>>
>> You guys rock!!
>>
>> I'm +1 on this,
>>
>> Can you please expand on the QA side of LTS. Since this is more around
>> long term bug/security fix - i'd think - the testing will be minimal, to
>> the scope that fix applies - which will speed up the release process in
>> general. What are your thoughts on this?
>>
>>
>> Thanks
>> ilya
>>
>>
>>
>>
>>
>> On 1/15/16 10:48 AM, John Burwell wrote:
>>> Motivation
>>> ========
>>>
>>> The current monthly release cycle addresses the needs of users focused
>>> on deploying new functionality as quickly as possible. It does not
>>> address the needs of users oriented towards stability rather than new
>>> functionality. These users typically employ QA processes to comply with
>>> corporate policy and/or regulatory requirements. To maintain a growing,
>>> thriving community, we must address the needs of both user types.
>>> Therefore, I propose that we overlay a LTS release cycle onto the
>>> monthly release cycle to address the needs of stability-oriented users
>>> with minimal to no impact on the monthly release cycle. This proposed
>>> LTS release cycle has the following goals:
>>>
>>> * Prefer Stability to New Functionality: Deliver releases that only
>>> address defects and CVEs. This narrowly focused change scope greatly
>>> reduces the upgrade risk/operational impact and shorter internal QA cycles.
>>> * Reliable Release Lifetimes: Embracing a time-based release strategy,
>>> the LTS release cycle will provide users with a reliable support time
>>> frames. Users can use these time frames provide users with an 20 month
>>> window in which to plan upgrades.
>>> * Support Sustainability: With a defined end of support for LTS releases
>>> and a maximum of two (2) LTS releases under active maintenance at any
>>> given time, community members can better plan their commitments to
>>> release support activities. We also have a agreed upon policy for
>>> release end-of-life (EOL) to debate about continuing work on old releases.
>>>
>>> Proposed Process
>>> ==============
>>>
>>> LTS release branches will be cut twice year on 1 Jan and 1 July from the
>>> tag of the most recent monthly release. The branch will be named <base
>>> version>-LTS and each LTS release will be versioned in the form of <base
>>> version>-<LTS revision number>. For example, if we cut an LTS branch
>>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version of
>>> the first LTS release would be 4.7.0-0, the second would be 4.7.0-1,
>>> etc. This release naming convention differentiates LTS and monthly
>>> releases, communicates the version on which the LTS release is based,
>>> and allows the maintenance releases for monthly releases without version
>>> number contention/conflict. Finally, like master, an LTS branch would be
>>> always deployable following its initial release. While it is unlikely
>>> that LTS users would deploy from the branch, the quality discipline of
>>> this requirement will benefit the long term stability of LTS releases.
>>> All PRs targeting an LTS would require two LGTMs in order to be merged.
>>>
>>> The following are the types of changes that would permitted and
>>> guarantees provided to users:
>>>
>>> * No features or enhancements would be backported to LTS release branches.
>>> * Database changes would be limited to those required to address the
>>> backported defect fixes.
>>> * Support for the release/version of the following components from the
>>> release on which the LTS is based throughout the entire release cycle:
>>> * MySQL/MariaDB
>>> * JDK/JRE
>>> * Linux distributions
>>> * API compatibility for between all LTS revisions. API changes would be
>>> limited to those required to fix defects or address security issues.
>>>
>>> An LTS release would have a twenty (20) month lifetime from the date the
>>> release branch is cut. This support period allows up to two (2) months
>>> of branch stabilization before initial release with a minimum of
>>> eighteen (18) months of availability for deployment. LTS releases would
>>> have the following support periods:
>>>
>>> * 0-14 months: backport all defect fixes in the scope of the LTS release
>>> functionality; fix all blocker and critical priority defects identified
>>> in the branch
>>> * 14-20 months: backport only CVE fixes in the scope of the LTS release
>>> functionality; fix all blocker priority defects in the branch
>>>
>>> Defect fixes that originate in an LTS branch will be pulled forward to
>>> master only. Finally, an LTS branch should be release the fewest times
>>> necessary to deliver fixes in a relatively timely manner. Therefore, LTS
>>> releases will be triggered based on the number of pending of fixes and
>>> their severity with no defect fix awaiting release more than forty-five
>>> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>>>
>>> Resourcing and Proposed Timeline
>>> ===========================
>>>
>>> Broad community support is vital to guarantee the twenty (20) month
>>> support period for each LTS branch. Given the ebbs and flows of
>>> contribution and committer priorities, ShapeBlue will provide a release
>>> manager, as well as, engineering support to fill any contribution gaps
>>> to ensure that the community fulfills LTS commitments.
>>>
>>> In order to prepare for supporting LTS releases, we would need to
>>> complete the following items:
>>>
>>> 1. All tools that do version number comparisons would be made aware of
>>> the LTS versioning scheme
>>> 2. Officially support running the management server on Java 8 since Java
>>> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the Java
>>> 1.8 compiler and run on Java 1.8). Providing a 20-month support window
>>> on an EOL JVM is an unacceptable security risk.
>>> 3. Update the wiki and website to explain the new release cycle and help
>>> users decide which release type suits their needs
>>> 4. Define an initial test plan for LTS stabilization
>>> 5. Agree on the definitions of ticket severities
>>>
>>> In order to address these items and start on a regular rhythm, I propose
>>> that first LTS cycle begin on 1 July 2015. In the interim, we would
>>> continue to ship critical bug fixes from the 4.5 release as this release
>>> seems to be the most commonly deployed in the community.
>>>
>>> Together, the monthly and LTS release cycles address the needs of the
>>> entire Apache CloudStack user community. I believe that the process
>>> described in the proposal will yield releases that meet the needs of
>>> users requiring release stability without adversely affecting the
>>> velocity of the monthly release cycle.
>>>
>>> Thanks,
>>> -John
>>>
>>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
>>>
>>>
>>> ShapeBlue <http://www.shapeblue.com>
>>> John Burwell
>>> ShapeBlue
>>>
>>> d:   *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
>>> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
>>>
>>> e:   *john.burwell@shapeblue.com | t: *
>>> <mailto:john.burwell@shapeblue.com%20|%20t:>          |      w:
>>> *www.shapeblue.com* <http://www.shapeblue.com>
>>>
>>> a:   53 Chandos Place, Covent Garden London WC2N 4HS UK
>>>
>>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>>> Services India LLP is a company incorporated in India and is operated
>>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>>> a company incorporated in Brasil and is operated under license from
>>> Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The
>>> Republic of South Africa and is traded under license from Shape Blue
>>> Ltd. ShapeBlue is a registered trademark.
>>> This email and any attachments to it may be confidential and are
>>> intended solely for the use of the individual to whom it is addressed.
>>> Any views or opinions expressed are solely those of the author and do
>>> not necessarily represent those of Shape Blue Ltd or related companies.
>>> If you are not the intended recipient of this email, you must neither
>>> take any action based upon its contents, nor copy or show it to anyone.
>>> Please contact the sender if you believe you have received this email in
>>> error.
>>>
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related services:
>>> IaaS Cloud Design & Build
>>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
>>> IaaS deployment framework <http://shapeblue.com/csforge/>
>>> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> |
>>> CloudStack Software Engineering
>>> <http://shapeblue.com/cloudstack-software-engineering/>
>>> CloudStack Infrastructure Support
>>> <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
>>> Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
> 
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>

Re: [PROPOSAL] LTS Release Cycle

Posted by John Burwell <jo...@shapeblue.com>.

Ilya,

Unless we have a bug fix that addresses a significant, widespread system stability problem or a high priority/impact security issue, an LTS will roll up a number of fixes.   Each release would receive the full system test to verify that the patch set does not introduce regression defects.  I believe that most LTS users want a few releases as necessary to keep their systems up-to-date and stable because each upgrade carries operational risk and downtime.  Therefore, the process should strive to make as a few releases as necessary to achieve this goal.

Thanks,
-John

> On Jan 15, 2016, at 3:22 PM, ilya <il...@gmail.com> wrote:
>
> John
>
> Thank you for taking time writing out the LTS proposal.
>
>> Broad community support is vital to guarantee the twenty (20) month
>> support period for each LTS branch. Given the ebbs and flows of
>> contribution and committer priorities, ShapeBlue will provide a release
>> manager, as well as, engineering support to fill any contribution gaps
>> to ensure that the community fulfills LTS commitments.
>
> You guys rock!!
>
> I'm +1 on this,
>
> Can you please expand on the QA side of LTS. Since this is more around
> long term bug/security fix - i'd think - the testing will be minimal, to
> the scope that fix applies - which will speed up the release process in
> general. What are your thoughts on this?
>
>
> Thanks
> ilya
>
>
>
>
>
> On 1/15/16 10:48 AM, John Burwell wrote:
>> Motivation
>> ========
>>
>> The current monthly release cycle addresses the needs of users focused
>> on deploying new functionality as quickly as possible. It does not
>> address the needs of users oriented towards stability rather than new
>> functionality. These users typically employ QA processes to comply with
>> corporate policy and/or regulatory requirements. To maintain a growing,
>> thriving community, we must address the needs of both user types.
>> Therefore, I propose that we overlay a LTS release cycle onto the
>> monthly release cycle to address the needs of stability-oriented users
>> with minimal to no impact on the monthly release cycle. This proposed
>> LTS release cycle has the following goals:
>>
>> * Prefer Stability to New Functionality: Deliver releases that only
>> address defects and CVEs. This narrowly focused change scope greatly
>> reduces the upgrade risk/operational impact and shorter internal QA cycles.
>> * Reliable Release Lifetimes: Embracing a time-based release strategy,
>> the LTS release cycle will provide users with a reliable support time
>> frames. Users can use these time frames provide users with an 20 month
>> window in which to plan upgrades.
>> * Support Sustainability: With a defined end of support for LTS releases
>> and a maximum of two (2) LTS releases under active maintenance at any
>> given time, community members can better plan their commitments to
>> release support activities. We also have a agreed upon policy for
>> release end-of-life (EOL) to debate about continuing work on old releases.
>>
>> Proposed Process
>> ==============
>>
>> LTS release branches will be cut twice year on 1 Jan and 1 July from the
>> tag of the most recent monthly release. The branch will be named <base
>> version>-LTS and each LTS release will be versioned in the form of <base
>> version>-<LTS revision number>. For example, if we cut an LTS branch
>> based on 4.7.0, the branch would be named 4.7.0-LTS and the version of
>> the first LTS release would be 4.7.0-0, the second would be 4.7.0-1,
>> etc. This release naming convention differentiates LTS and monthly
>> releases, communicates the version on which the LTS release is based,
>> and allows the maintenance releases for monthly releases without version
>> number contention/conflict. Finally, like master, an LTS branch would be
>> always deployable following its initial release. While it is unlikely
>> that LTS users would deploy from the branch, the quality discipline of
>> this requirement will benefit the long term stability of LTS releases.
>> All PRs targeting an LTS would require two LGTMs in order to be merged.
>>
>> The following are the types of changes that would permitted and
>> guarantees provided to users:
>>
>> * No features or enhancements would be backported to LTS release branches.
>> * Database changes would be limited to those required to address the
>> backported defect fixes.
>> * Support for the release/version of the following components from the
>> release on which the LTS is based throughout the entire release cycle:
>> * MySQL/MariaDB
>> * JDK/JRE
>> * Linux distributions
>> * API compatibility for between all LTS revisions. API changes would be
>> limited to those required to fix defects or address security issues.
>>
>> An LTS release would have a twenty (20) month lifetime from the date the
>> release branch is cut. This support period allows up to two (2) months
>> of branch stabilization before initial release with a minimum of
>> eighteen (18) months of availability for deployment. LTS releases would
>> have the following support periods:
>>
>> * 0-14 months: backport all defect fixes in the scope of the LTS release
>> functionality; fix all blocker and critical priority defects identified
>> in the branch
>> * 14-20 months: backport only CVE fixes in the scope of the LTS release
>> functionality; fix all blocker priority defects in the branch
>>
>> Defect fixes that originate in an LTS branch will be pulled forward to
>> master only. Finally, an LTS branch should be release the fewest times
>> necessary to deliver fixes in a relatively timely manner. Therefore, LTS
>> releases will be triggered based on the number of pending of fixes and
>> their severity with no defect fix awaiting release more than forty-five
>> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>>
>> Resourcing and Proposed Timeline
>> ===========================
>>
>> Broad community support is vital to guarantee the twenty (20) month
>> support period for each LTS branch. Given the ebbs and flows of
>> contribution and committer priorities, ShapeBlue will provide a release
>> manager, as well as, engineering support to fill any contribution gaps
>> to ensure that the community fulfills LTS commitments.
>>
>> In order to prepare for supporting LTS releases, we would need to
>> complete the following items:
>>
>> 1. All tools that do version number comparisons would be made aware of
>> the LTS versioning scheme
>> 2. Officially support running the management server on Java 8 since Java
>> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the Java
>> 1.8 compiler and run on Java 1.8). Providing a 20-month support window
>> on an EOL JVM is an unacceptable security risk.
>> 3. Update the wiki and website to explain the new release cycle and help
>> users decide which release type suits their needs
>> 4. Define an initial test plan for LTS stabilization
>> 5. Agree on the definitions of ticket severities
>>
>> In order to address these items and start on a regular rhythm, I propose
>> that first LTS cycle begin on 1 July 2015. In the interim, we would
>> continue to ship critical bug fixes from the 4.5 release as this release
>> seems to be the most commonly deployed in the community.
>>
>> Together, the monthly and LTS release cycles address the needs of the
>> entire Apache CloudStack user community. I believe that the process
>> described in the proposal will yield releases that meet the needs of
>> users requiring release stability without adversely affecting the
>> velocity of the monthly release cycle.
>>
>> Thanks,
>> -John
>>
>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
>>
>>
>> ShapeBlue <http://www.shapeblue.com>
>> John Burwell
>> ShapeBlue
>>
>> d:   *+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
>> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
>>
>> e:   *john.burwell@shapeblue.com | t: *
>> <mailto:john.burwell@shapeblue.com%20|%20t:>          |      w:
>> *www.shapeblue.com* <http://www.shapeblue.com>
>>
>> a:   53 Chandos Place, Covent Garden London WC2N 4HS UK
>>
>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>> Services India LLP is a company incorporated in India and is operated
>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>> a company incorporated in Brasil and is operated under license from
>> Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The
>> Republic of South Africa and is traded under license from Shape Blue
>> Ltd. ShapeBlue is a registered trademark.
>> This email and any attachments to it may be confidential and are
>> intended solely for the use of the individual to whom it is addressed.
>> Any views or opinions expressed are solely those of the author and do
>> not necessarily represent those of Shape Blue Ltd or related companies.
>> If you are not the intended recipient of this email, you must neither
>> take any action based upon its contents, nor copy or show it to anyone.
>> Please contact the sender if you believe you have received this email in
>> error.
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services:
>> IaaS Cloud Design & Build
>> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
>> IaaS deployment framework <http://shapeblue.com/csforge/>
>> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> |
>> CloudStack Software Engineering
>> <http://shapeblue.com/cloudstack-software-engineering/>
>> CloudStack Infrastructure Support
>> <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
>> Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by ilya <il...@gmail.com>.

John

Thank you for taking time writing out the LTS proposal.

>  Broad community support is vital to guarantee the twenty (20) month
> support period for each LTS branch. Given the ebbs and flows of
> contribution and committer priorities, ShapeBlue will provide a release
> manager, as well as, engineering support to fill any contribution gaps
> to ensure that the community fulfills LTS commitments.

You guys rock!!

I'm +1 on this,

Can you please expand on the QA side of LTS. Since this is more around
long term bug/security fix - i'd think - the testing will be minimal, to
the scope that fix applies - which will speed up the release process in
general. What are your thoughts on this?


Thanks
ilya





On 1/15/16 10:48 AM, John Burwell wrote:
> Motivation
> ========
> 
> The current monthly release cycle addresses the needs of users focused
> on deploying new functionality as quickly as possible. It does not
> address the needs of users oriented towards stability rather than new
> functionality. These users typically employ QA processes to comply with
> corporate policy and/or regulatory requirements. To maintain a growing,
> thriving community, we must address the needs of both user types.
> Therefore, I propose that we overlay a LTS release cycle onto the
> monthly release cycle to address the needs of stability-oriented users
> with minimal to no impact on the monthly release cycle. This proposed
> LTS release cycle has the following goals:
> 
> * Prefer Stability to New Functionality: Deliver releases that only
> address defects and CVEs. This narrowly focused change scope greatly
> reduces the upgrade risk/operational impact and shorter internal QA cycles.
> * Reliable Release Lifetimes: Embracing a time-based release strategy,
> the LTS release cycle will provide users with a reliable support time
> frames. Users can use these time frames provide users with an 20 month
> window in which to plan upgrades.
> * Support Sustainability: With a defined end of support for LTS releases
> and a maximum of two (2) LTS releases under active maintenance at any
> given time, community members can better plan their commitments to
> release support activities. We also have a agreed upon policy for
> release end-of-life (EOL) to debate about continuing work on old releases.
> 
> Proposed Process
> ==============
> 
> LTS release branches will be cut twice year on 1 Jan and 1 July from the
> tag of the most recent monthly release. The branch will be named <base
> version>-LTS and each LTS release will be versioned in the form of <base
> version>-<LTS revision number>. For example, if we cut an LTS branch
> based on 4.7.0, the branch would be named 4.7.0-LTS and the version of
> the first LTS release would be 4.7.0-0, the second would be 4.7.0-1,
> etc. This release naming convention differentiates LTS and monthly
> releases, communicates the version on which the LTS release is based,
> and allows the maintenance releases for monthly releases without version
> number contention/conflict. Finally, like master, an LTS branch would be
> always deployable following its initial release. While it is unlikely
> that LTS users would deploy from the branch, the quality discipline of
> this requirement will benefit the long term stability of LTS releases.
> All PRs targeting an LTS would require two LGTMs in order to be merged.
> 
> The following are the types of changes that would permitted and
> guarantees provided to users:
> 
> * No features or enhancements would be backported to LTS release branches.
> * Database changes would be limited to those required to address the
> backported defect fixes.
> * Support for the release/version of the following components from the
> release on which the LTS is based throughout the entire release cycle:
> * MySQL/MariaDB
> * JDK/JRE
> * Linux distributions
> * API compatibility for between all LTS revisions. API changes would be
> limited to those required to fix defects or address security issues.
> 
> An LTS release would have a twenty (20) month lifetime from the date the
> release branch is cut. This support period allows up to two (2) months
> of branch stabilization before initial release with a minimum of
> eighteen (18) months of availability for deployment. LTS releases would
> have the following support periods:
> 
> * 0-14 months: backport all defect fixes in the scope of the LTS release
> functionality; fix all blocker and critical priority defects identified
> in the branch
> * 14-20 months: backport only CVE fixes in the scope of the LTS release
> functionality; fix all blocker priority defects in the branch
> 
> Defect fixes that originate in an LTS branch will be pulled forward to
> master only. Finally, an LTS branch should be release the fewest times
> necessary to deliver fixes in a relatively timely manner. Therefore, LTS
> releases will be triggered based on the number of pending of fixes and
> their severity with no defect fix awaiting release more than forty-five
> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
> 
> Resourcing and Proposed Timeline
> ===========================
> 
> Broad community support is vital to guarantee the twenty (20) month
> support period for each LTS branch. Given the ebbs and flows of
> contribution and committer priorities, ShapeBlue will provide a release
> manager, as well as, engineering support to fill any contribution gaps
> to ensure that the community fulfills LTS commitments.
> 
> In order to prepare for supporting LTS releases, we would need to
> complete the following items:
> 
> 1. All tools that do version number comparisons would be made aware of
> the LTS versioning scheme
> 2. Officially support running the management server on Java 8 since Java
> 7 has been EOL since last April [1] (i.e. compile to 1.7 with the Java
> 1.8 compiler and run on Java 1.8). Providing a 20-month support window
> on an EOL JVM is an unacceptable security risk.
> 3. Update the wiki and website to explain the new release cycle and help
> users decide which release type suits their needs
> 4. Define an initial test plan for LTS stabilization
> 5. Agree on the definitions of ticket severities
> 
> In order to address these items and start on a regular rhythm, I propose
> that first LTS cycle begin on 1 July 2015. In the interim, we would
> continue to ship critical bug fixes from the 4.5 release as this release
> seems to be the most commonly deployed in the community.
> 
> Together, the monthly and LTS release cycles address the needs of the
> entire Apache CloudStack user community. I believe that the process
> described in the proposal will yield releases that meet the needs of
> users requiring release stability without adversely affecting the
> velocity of the monthly release cycle.
> 
> Thanks,
> -John
> 
> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
> 
> 
> ShapeBlue <http://www.shapeblue.com> 	
> John Burwell
> ShapeBlue
> 
> d:  	*+44 (20) 3603 0542 | s: +1 (571) 403-2411 *
> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
> 
> e:  	*john.burwell@shapeblue.com | t: *
> <mailto:john.burwell@shapeblue.com%20|%20t:> 	 |  	w: 
> *www.shapeblue.com* <http://www.shapeblue.com>
> 
> a:  	53 Chandos Place, Covent Garden London WC2N 4HS UK
> 
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated
> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
> a company incorporated in Brasil and is operated under license from
> Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The
> Republic of South Africa and is traded under license from Shape Blue
> Ltd. ShapeBlue is a registered trademark.
> This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is addressed.
> Any views or opinions expressed are solely those of the author and do
> not necessarily represent those of Shape Blue Ltd or related companies.
> If you are not the intended recipient of this email, you must neither
> take any action based upon its contents, nor copy or show it to anyone.
> Please contact the sender if you believe you have received this email in
> error.
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build
> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
> IaaS deployment framework <http://shapeblue.com/csforge/>
> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> |
> CloudStack Software Engineering
> <http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support
> <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by John Burwell <jo...@shapeblue.com>.

All,

LTS branches will be maintained for 20 months. In that time, some defects will be fixed in an LTS branch and forward merged. Some defects will be identified in master, and we will need to determine whether or not they should be pulled back to one or more of the active LTS branches. As master evolves, there will not always be a straight line from LTS to master. Requiring a direct path between LTS branches and master would either severely constrain the development of master or compromise the stability expected by LTS users. We should also not assume that all backports will be merges/cherry picks — some will be re-implementations due to divergence over time. Like the Ubuntu and Red Hat maintenance cycles, the proposal places the burden of determining the best approach to defect backporting on LTS maintainers to avoid impacting the velocity of feature development. While we should prefer fixing in LTS merging forward, the reality is that maintaining long running maintenance branches will require some cherry picking and re-implementation of defects due to the length of the support window.

It’s also important to note I propose only pulling back blockers and critical severity defects within the scope of the LTS’ functionality from master. The goal of LTS is not to fix every defect. It is to fix those defects that impact system stability or severely degrade functionality. Previously, we conflated feature development and maintenance into a single set of release branches using the same release cycle. With the monthly releases, users have a path to acquire new functionality independent of bug fix/maintenance efforts — removing potential justification to pull back new features or enhancements. As we have discussed this proposal, I think it should be amended to require that all PRs to an LTS branch include an LGTM from the LTS branch RM to ensure that only defects that fit within the narrowly defined constraints.

Based on our history, I share your concerns about cherry picking abuse, and have attempt to design the proposal to address them. I believe that the tighter constraints on the defects that are allowed to be backported, a clearly defined policy about the LTS release cycle schedule, and monthly releases will allow us to avoid the mistakes of the past.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:      john.burwell@shapeblue.com | t: <mailto:john.burwell@shapeblue.com%20|%20t:>     |      w:      www.shapeblue.com<http://www.shapeblue.com>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK

[cid:imagefafe75.png@d43a0b58.41a20f1c]

Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

On Jan 19, 2016, at 6:14 AM, Daan Hoogland <da...@gmail.com> wrote:
>
> Jeff, That we did before. I don't think that's good enough. It must be the
> same commit as far as I'm concerned. Any conflict will be made explicit in
> a merge commit that way.
>
> On Tue, Jan 19, 2016 at 12:08 PM, Jeff Hair <je...@greenqloud.com> wrote:
>
>> Maybe require all cherry-picks to use the -x option, which puts the
>> original commit hash in the cherry-picked commit message?
>>
>> On Tue, Jan 19, 2016 at 10:53 AM, Remi Bergsma <
>> RBergsma@schubergphilis.com>
>> wrote:
>>
>>> On a certain night when a release had been cut and there was some worry
>>> about a security fix not being included. The root cause was that we
>>> cherry-picked that fix and as a result its commit hash had changed. Hence
>>> we couldn’t find it.
>>>
>>> I’d recommend using forward merging instead of back porting aka
>>> cherry-picking, so the commit hashes stay the same and fixes are easily
>>> traceable.
>>>
>>> Just my $0.02.
>>>
>>> Regards,
>>> Remi
>>>
>>>
>>>
>>>
>>>
>>> On 19/01/16 08:45, "Daan Hoogland" <da...@gmail.com> wrote:
>>>
>>>> On Tue, Jan 19, 2016 at 4:20 AM, John Burwell <
>> john.burwell@shapeblue.com
>>>>
>>>> wrote:
>>>>
>>>>> In terms of the merge strategy, nothing about the current process
>> would
>>>>> change. Defects would be fixed on the branch where they occurred and
>>> then
>>>>> forward ported to master. For each maintained LTS branch less than 14
>>>>> months old, only blocker and critical defects that fall within the
>> LTS’
>>>>> branch scope would be pulled back from master. Therefore, the number
>> of
>>>>> defects backported should be relatively small. Any defects found and
>>> fixed
>>>>> in an LTS branch would be forward ported to master. I will clarify the
>>>>> proposal to establish this merge pattern to ensure that LTS does not
>>>>> violate or impede the flow of defect fixes on master and maintained
>>> monthly
>>>>> releases.
>>>>>
>>>>
>>>> John, Any backporting should be avoided. Any fix review should include
>>> the
>>>> contemplation of the question, 'Is this on the right branch?'. That is
>> my
>>>> point. I am not against LTS. I want fixes to be traceable by their
>> commit
>>>> id over all branches. Backporting is killing in that respect.
>>>>
>>>> I am not the release manager so rest assured I will not make an issue
>> of
>>>> this any more. I won't hold my peace either, though.
>>>>
>>>>
>>>> --
>>>> Daan
>>>
>>
>>
>>
>> --
>> *Jeff Hair*
>> Technical Lead and Software Developer
>>
>> Tel: (+354) 415 0200
>> jeff@greenqloud.com
>> www.greenqloud.com
>>
>
>
>
> --
> Daan

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by Daan Hoogland <da...@gmail.com>.

Jeff, That we did before. I don't think that's good enough. It must be the
same commit as far as I'm concerned. Any conflict will be made explicit in
a merge commit that way.

On Tue, Jan 19, 2016 at 12:08 PM, Jeff Hair <je...@greenqloud.com> wrote:

> Maybe require all cherry-picks to use the -x option, which puts the
> original commit hash in the cherry-picked commit message?
>
> On Tue, Jan 19, 2016 at 10:53 AM, Remi Bergsma <
> RBergsma@schubergphilis.com>
> wrote:
>
> > On a certain night when a release had been cut and there was some worry
> > about a security fix not being included. The root cause was that we
> > cherry-picked that fix and as a result its commit hash had changed. Hence
> > we couldn’t find it.
> >
> > I’d recommend using forward merging instead of back porting aka
> > cherry-picking, so the commit hashes stay the same and fixes are easily
> > traceable.
> >
> > Just my $0.02.
> >
> > Regards,
> > Remi
> >
> >
> >
> >
> >
> > On 19/01/16 08:45, "Daan Hoogland" <da...@gmail.com> wrote:
> >
> > >On Tue, Jan 19, 2016 at 4:20 AM, John Burwell <
> john.burwell@shapeblue.com
> > >
> > >wrote:
> > >
> > >> In terms of the merge strategy, nothing about the current process
> would
> > >> change. Defects would be fixed on the branch where they occurred and
> > then
> > >> forward ported to master. For each maintained LTS branch less than 14
> > >> months old, only blocker and critical defects that fall within the
> LTS’
> > >> branch scope would be pulled back from master. Therefore, the number
> of
> > >> defects backported should be relatively small. Any defects found and
> > fixed
> > >> in an LTS branch would be forward ported to master. I will clarify the
> > >> proposal to establish this merge pattern to ensure that LTS does not
> > >> violate or impede the flow of defect fixes on master and maintained
> > monthly
> > >> releases.
> > >>
> > >
> > >John, Any backporting should be avoided. Any fix review should include
> > the
> > >contemplation of the question, 'Is this on the right branch?'. That is
> my
> > >point. I am not against LTS. I want fixes to be traceable by their
> commit
> > >id over all branches. Backporting is killing in that respect.
> > >
> > >I am not the release manager so rest assured I will not make an issue
> of
> > >this any more. I won't hold my peace either, though.
> > >
> > >
> > >--
> > >Daan
> >
>
>
>
> --
> *Jeff Hair*
> Technical Lead and Software Developer
>
> Tel: (+354) 415 0200
> jeff@greenqloud.com
> www.greenqloud.com
>



-- 
Daan

Re: [PROPOSAL] LTS Release Cycle

Posted by Jeff Hair <je...@greenqloud.com>.

Maybe require all cherry-picks to use the -x option, which puts the
original commit hash in the cherry-picked commit message?

On Tue, Jan 19, 2016 at 10:53 AM, Remi Bergsma <RB...@schubergphilis.com>
wrote:

> On a certain night when a release had been cut and there was some worry
> about a security fix not being included. The root cause was that we
> cherry-picked that fix and as a result its commit hash had changed. Hence
> we couldn’t find it.
>
> I’d recommend using forward merging instead of back porting aka
> cherry-picking, so the commit hashes stay the same and fixes are easily
> traceable.
>
> Just my $0.02.
>
> Regards,
> Remi
>
>
>
>
>
> On 19/01/16 08:45, "Daan Hoogland" <da...@gmail.com> wrote:
>
> >On Tue, Jan 19, 2016 at 4:20 AM, John Burwell <john.burwell@shapeblue.com
> >
> >wrote:
> >
> >> In terms of the merge strategy, nothing about the current process would
> >> change. Defects would be fixed on the branch where they occurred and
> then
> >> forward ported to master. For each maintained LTS branch less than 14
> >> months old, only blocker and critical defects that fall within the LTS’
> >> branch scope would be pulled back from master. Therefore, the number of
> >> defects backported should be relatively small. Any defects found and
> fixed
> >> in an LTS branch would be forward ported to master. I will clarify the
> >> proposal to establish this merge pattern to ensure that LTS does not
> >> violate or impede the flow of defect fixes on master and maintained
> monthly
> >> releases.
> >>
> >
> >John, Any backporting should be avoided. Any fix review should include
> the
> >contemplation of the question, 'Is this on the right branch?'. That is my
> >point. I am not against LTS. I want fixes to be traceable by their commit
> >id over all branches. Backporting is killing in that respect.
> >
> >I am not the release manager so rest assured I will not make an issue of
> >this any more. I won't hold my peace either, though.
> >
> >
> >--
> >Daan
>



-- 
*Jeff Hair*
Technical Lead and Software Developer

Tel: (+354) 415 0200
jeff@greenqloud.com
www.greenqloud.com

Re: [PROPOSAL] LTS Release Cycle

Posted by Remi Bergsma <RB...@schubergphilis.com>.

On a certain night when a release had been cut and there was some worry about a security fix not being included. The root cause was that we cherry-picked that fix and as a result its commit hash had changed. Hence we couldn’t find it.

I’d recommend using forward merging instead of back porting aka cherry-picking, so the commit hashes stay the same and fixes are easily traceable. 

Just my $0.02.

Regards,
Remi





On 19/01/16 08:45, "Daan Hoogland" <da...@gmail.com> wrote:

>On Tue, Jan 19, 2016 at 4:20 AM, John Burwell <jo...@shapeblue.com>
>wrote:
>
>> In terms of the merge strategy, nothing about the current process would
>> change. Defects would be fixed on the branch where they occurred and then
>> forward ported to master. For each maintained LTS branch less than 14
>> months old, only blocker and critical defects that fall within the LTS’
>> branch scope would be pulled back from master. Therefore, the number of
>> defects backported should be relatively small. Any defects found and fixed
>> in an LTS branch would be forward ported to master. I will clarify the
>> proposal to establish this merge pattern to ensure that LTS does not
>> violate or impede the flow of defect fixes on master and maintained monthly
>> releases.
>>
>
>John, Any backporting should be avoided. Any fix review should include the
>contemplation of the question, 'Is this on the right branch?'. That is my
>point. I am not against LTS. I want fixes to be traceable by their commit
>id over all branches. Backporting is killing in that respect.
>
>I am not the release manager so rest assured I will not make an issue of
>this any more. I won't hold my peace either, though.
>
>
>-- 
>Daan

Re: [PROPOSAL] LTS Release Cycle

Posted by Nux! <nu...@li.nux.ro>.

+1 LTS, but FWIW I also think Daan has a point here and it should be taken into consideration.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Daan Hoogland" <da...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Sent: Tuesday, 19 January, 2016 07:45:57
> Subject: Re: [PROPOSAL] LTS Release Cycle

> On Tue, Jan 19, 2016 at 4:20 AM, John Burwell <jo...@shapeblue.com>
> wrote:
> 
>> In terms of the merge strategy, nothing about the current process would
>> change. Defects would be fixed on the branch where they occurred and then
>> forward ported to master. For each maintained LTS branch less than 14
>> months old, only blocker and critical defects that fall within the LTS’
>> branch scope would be pulled back from master. Therefore, the number of
>> defects backported should be relatively small. Any defects found and fixed
>> in an LTS branch would be forward ported to master. I will clarify the
>> proposal to establish this merge pattern to ensure that LTS does not
>> violate or impede the flow of defect fixes on master and maintained monthly
>> releases.
>>
> 
> John, Any backporting should be avoided. Any fix review should include the
> contemplation of the question, 'Is this on the right branch?'. That is my
> point. I am not against LTS. I want fixes to be traceable by their commit
> id over all branches. Backporting is killing in that respect.
> 
> I am not the release manager so rest assured I will not make an issue of
> this any more. I won't hold my peace either, though.
> 
> 
> --
> Daan

Re: [PROPOSAL] LTS Release Cycle

Posted by Daan Hoogland <da...@gmail.com>.

On Tue, Jan 19, 2016 at 4:20 AM, John Burwell <jo...@shapeblue.com>
wrote:

> In terms of the merge strategy, nothing about the current process would
> change. Defects would be fixed on the branch where they occurred and then
> forward ported to master. For each maintained LTS branch less than 14
> months old, only blocker and critical defects that fall within the LTS’
> branch scope would be pulled back from master. Therefore, the number of
> defects backported should be relatively small. Any defects found and fixed
> in an LTS branch would be forward ported to master. I will clarify the
> proposal to establish this merge pattern to ensure that LTS does not
> violate or impede the flow of defect fixes on master and maintained monthly
> releases.
>

John, Any backporting should be avoided. Any fix review should include the
contemplation of the question, 'Is this on the right branch?'. That is my
point. I am not against LTS. I want fixes to be traceable by their commit
id over all branches. Backporting is killing in that respect.

I am not the release manager so rest assured I will not make an issue of
this any more. I won't hold my peace either, though.

-- 
Daan

Re: [PROPOSAL] LTS Release Cycle

Posted by John Burwell <jo...@shapeblue.com>.

Daan and Erik,

@Erik Reading through the proposal, I realize that I was not explicit. LTS releases would be official ASF releases following the same voting procedures as any other release. Also, realized that I have a bit a math fail in my proposal. The cut dates are intended to be six (6) months apart. Therefore, the cut dates should be 1 January and 1 June. Therefore, I propose that we cut the first LTS branch from the most recent monthly release as of 1 June 2016.

@Daan As many people reflected in the previous discussion about release cadence, many users are wedged between enduring workarounds for significant defects and a level of upgrade risk that is not acceptable to them. For these users, releases are in use for 12-18 months which means that they are often forced to accept some significant workarounds to keep their systems stable (e.g. 4.5.2 VMWare users can’t use DRS with advanced networking due to VR being rebooted on DRS migrations). Keeping all of the previous monthly releases updated with important bug fixes is not tenable. LTS allows us to maintain a release branch to support users who must run a release for a 12-18 months without having to compromise their operational capability to preserve system stability.

In terms of the merge strategy, nothing about the current process would change. Defects would be fixed on the branch where they occurred and then forward ported to master. For each maintained LTS branch less than 14 months old, only blocker and critical defects that fall within the LTS’ branch scope would be pulled back from master. Therefore, the number of defects backported should be relatively small. Any defects found and fixed in an LTS branch would be forward ported to master. I will clarify the proposal to establish this merge pattern to ensure that LTS does not violate or impede the flow of defect fixes on master and maintained monthly releases.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:      john.burwell@shapeblue.com | t: <mailto:john.burwell@shapeblue.com%20|%20t:>     |      w:      www.shapeblue.com<http://www.shapeblue.com>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imageff218b.png@a664b8fc.4fa0ac20]


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.




On Jan 16, 2016, at 5:07 AM, Daan Hoogland <da...@gmail.com> wrote:
>
> +0, John, I admire your efforts but I would like to see a proposal more in
> line with our present process for PR merging and releasing. For 4.5 we have
> a bootstrap problem, here so that would reauire a transistion period
> (unless we start branding our LTS on 4.7) I also don see the neccesity for
> anything beyond tiny version. I think it is confusing. So I would prefer
> going for 4.7.1 ...2 ...3 etc or 4.5.4 ...5 ...6 if you wish. And next I am
> not attracted to the back-porting bit. We should make sure bugs are fixed
> on the commit that caused them and then forward ported to any branch that
> needs them, including master and LTS.
>
> That all said, I see a feasible plan so please go ahead.
>
> On Fri, Jan 15, 2016 at 10:26 PM, Erik Weber <te...@gmail.com> wrote:
>
>> On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <jo...@shapeblue.com>
>> wrote:
>>
>>> Motivation
>>> ========
>>>
>>> The current monthly release cycle addresses the needs of users focused on
>>> deploying new functionality as quickly as possible. It does not address
>> the
>>> needs of users oriented towards stability rather than new functionality.
>>> These users typically employ QA processes to comply with corporate policy
>>> and/or regulatory requirements. To maintain a growing, thriving
>> community,
>>> we must address the needs of both user types. Therefore, I propose that
>> we
>>> overlay a LTS release cycle onto the monthly release cycle to address the
>>> needs of stability-oriented users with minimal to no impact on the
>> monthly
>>> release cycle. This proposed LTS release cycle has the following goals:
>>>
>>> * Prefer Stability to New Functionality: Deliver releases that only
>>> address defects and CVEs. This narrowly focused change scope greatly
>>> reduces the upgrade risk/operational impact and shorter internal QA
>> cycles.
>>> * Reliable Release Lifetimes: Embracing a time-based release strategy,
>> the
>>> LTS release cycle will provide users with a reliable support time frames.
>>> Users can use these time frames provide users with an 20 month window in
>>> which to plan upgrades.
>>> * Support Sustainability: With a defined end of support for LTS releases
>>> and a maximum of two (2) LTS releases under active maintenance at any
>> given
>>> time, community members can better plan their commitments to release
>>> support activities. We also have a agreed upon policy for release
>>> end-of-life (EOL) to debate about continuing work on old releases.
>>>
>>> Proposed Process
>>> ==============
>>>
>>> LTS release branches will be cut twice year on 1 Jan and 1 July from the
>>> tag of the most recent monthly release. The branch will be named <base
>>> version>-LTS and each LTS release will be versioned in the form of <base
>>> version>-<LTS revision number>. For example, if we cut an LTS branch
>> based
>>> on 4.7.0, the branch would be named 4.7.0-LTS and the version of the
>> first
>>> LTS release would be 4.7.0-0, the second would be 4.7.0-1, etc. This
>>> release naming convention differentiates LTS and monthly releases,
>>> communicates the version on which the LTS release is based, and allows
>> the
>>> maintenance releases for monthly releases without version number
>>> contention/conflict. Finally, like master, an LTS branch would be always
>>> deployable following its initial release. While it is unlikely that LTS
>>> users would deploy from the branch, the quality discipline of this
>>> requirement will benefit the long term stability of LTS releases. All PRs
>>> targeting an LTS would require two LGTMs in order to be merged.
>>>
>>> The following are the types of changes that would permitted and
>> guarantees
>>> provided to users:
>>>
>>> * No features or enhancements would be backported to LTS release
>> branches.
>>> * Database changes would be limited to those required to address the
>>> backported defect fixes.
>>> * Support for the release/version of the following components from the
>>> release on which the LTS is based throughout the entire release cycle:
>>> * MySQL/MariaDB
>>> * JDK/JRE
>>> * Linux distributions
>>> * API compatibility for between all LTS revisions. API changes would be
>>> limited to those required to fix defects or address security issues.
>>>
>>> An LTS release would have a twenty (20) month lifetime from the date the
>>> release branch is cut. This support period allows up to two (2) months of
>>> branch stabilization before initial release with a minimum of eighteen
>> (18)
>>> months of availability for deployment. LTS releases would have the
>>> following support periods:
>>>
>>> * 0-14 months: backport all defect fixes in the scope of the LTS release
>>> functionality; fix all blocker and critical priority defects identified
>> in
>>> the branch
>>> * 14-20 months: backport only CVE fixes in the scope of the LTS release
>>> functionality; fix all blocker priority defects in the branch
>>>
>>> Defect fixes that originate in an LTS branch will be pulled forward to
>>> master only. Finally, an LTS branch should be release the fewest times
>>> necessary to deliver fixes in a relatively timely manner. Therefore, LTS
>>> releases will be triggered based on the number of pending of fixes and
>>> their severity with no defect fix awaiting release more than forty-five
>>> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>>>
>>>
>>
>> Is this going to be official ASF CloudStack releases following the
>> necessary protocol of vote periods, binding votes etc. or will this be a
>> community release by 3rd parties?
>> I am asking now so that we are all on the same page here when we get to the
>> first release.
>>
>>
>>> Resourcing and Proposed Timeline
>>> ===========================
>>>
>>> Broad community support is vital to guarantee the twenty (20) month
>>> support period for each LTS branch. Given the ebbs and flows of
>>> contribution and committer priorities, ShapeBlue will provide a release
>>> manager, as well as, engineering support to fill any contribution gaps to
>>> ensure that the community fulfills LTS commitments.
>>>
>>> In order to prepare for supporting LTS releases, we would need to
>> complete
>>> the following items:
>>>
>>> 1. All tools that do version number comparisons would be made aware of
>> the
>>> LTS versioning scheme
>>> 2. Officially support running the management server on Java 8 since Java
>> 7
>>> has been EOL since last April [1] (i.e. compile to 1.7 with the Java 1.8
>>> compiler and run on Java 1.8). Providing a 20-month support window on an
>>> EOL JVM is an unacceptable security risk.
>>> 3. Update the wiki and website to explain the new release cycle and help
>>> users decide which release type suits their needs
>>> 4. Define an initial test plan for LTS stabilization
>>> 5. Agree on the definitions of ticket severities
>>>
>>> In order to address these items and start on a regular rhythm, I propose
>>> that first LTS cycle begin on 1 July 2015. In the interim, we would
>>> continue to ship critical bug fixes from the 4.5 release as this release
>>> seems to be the most commonly deployed in the community.
>>>
>>
>> 1 July 2016 I assume? :-)
>>
>>
>>>
>>> Together, the monthly and LTS release cycles address the needs of the
>>> entire Apache CloudStack user community. I believe that the process
>>> described in the proposal will yield releases that meet the needs of
>> users
>>> requiring release stability without adversely affecting the velocity of
>> the
>>> monthly release cycle.
>>>
>>>
>>
>> Huge +1.
>> I understand that a lot of people want fast and rapid releases, but that
>> does not work for everyone, me included. I'll most likely run LTS in
>> production, but latest monthly in labs/testing.
>>
>>
>>
>> --
>> Erik
>>
>
>
>
> --
> Daan

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [PROPOSAL] LTS Release Cycle

Posted by Daan Hoogland <da...@gmail.com>.

+0, John, I admire your efforts but I would like to see a proposal more in
line with our present process for PR merging and releasing. For 4.5 we have
a bootstrap problem, here so that would reauire a transistion period
(unless we start branding our LTS on 4.7) I also don see the neccesity for
anything beyond tiny version. I think it is confusing. So I would prefer
going for 4.7.1 ...2 ...3 etc or 4.5.4 ...5 ...6 if you wish. And next I am
not attracted to the back-porting bit. We should make sure bugs are fixed
on the commit that caused them and then forward ported to any branch that
needs them, including master and LTS.

That all said, I see a feasible plan so please go ahead.

On Fri, Jan 15, 2016 at 10:26 PM, Erik Weber <te...@gmail.com> wrote:

> On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <jo...@shapeblue.com>
> wrote:
>
> > Motivation
> > ========
> >
> > The current monthly release cycle addresses the needs of users focused on
> > deploying new functionality as quickly as possible. It does not address
> the
> > needs of users oriented towards stability rather than new functionality.
> > These users typically employ QA processes to comply with corporate policy
> > and/or regulatory requirements. To maintain a growing, thriving
> community,
> > we must address the needs of both user types. Therefore, I propose that
> we
> > overlay a LTS release cycle onto the monthly release cycle to address the
> > needs of stability-oriented users with minimal to no impact on the
> monthly
> > release cycle. This proposed LTS release cycle has the following goals:
> >
> > * Prefer Stability to New Functionality: Deliver releases that only
> > address defects and CVEs. This narrowly focused change scope greatly
> > reduces the upgrade risk/operational impact and shorter internal QA
> cycles.
> > * Reliable Release Lifetimes: Embracing a time-based release strategy,
> the
> > LTS release cycle will provide users with a reliable support time frames.
> > Users can use these time frames provide users with an 20 month window in
> > which to plan upgrades.
> > * Support Sustainability: With a defined end of support for LTS releases
> > and a maximum of two (2) LTS releases under active maintenance at any
> given
> > time, community members can better plan their commitments to release
> > support activities. We also have a agreed upon policy for release
> > end-of-life (EOL) to debate about continuing work on old releases.
> >
> > Proposed Process
> > ==============
> >
> > LTS release branches will be cut twice year on 1 Jan and 1 July from the
> > tag of the most recent monthly release. The branch will be named <base
> > version>-LTS and each LTS release will be versioned in the form of <base
> > version>-<LTS revision number>. For example, if we cut an LTS branch
> based
> > on 4.7.0, the branch would be named 4.7.0-LTS and the version of the
> first
> > LTS release would be 4.7.0-0, the second would be 4.7.0-1, etc. This
> > release naming convention differentiates LTS and monthly releases,
> > communicates the version on which the LTS release is based, and allows
> the
> > maintenance releases for monthly releases without version number
> > contention/conflict. Finally, like master, an LTS branch would be always
> > deployable following its initial release. While it is unlikely that LTS
> > users would deploy from the branch, the quality discipline of this
> > requirement will benefit the long term stability of LTS releases. All PRs
> > targeting an LTS would require two LGTMs in order to be merged.
> >
> > The following are the types of changes that would permitted and
> guarantees
> > provided to users:
> >
> > * No features or enhancements would be backported to LTS release
> branches.
> > * Database changes would be limited to those required to address the
> > backported defect fixes.
> > * Support for the release/version of the following components from the
> > release on which the LTS is based throughout the entire release cycle:
> > * MySQL/MariaDB
> > * JDK/JRE
> > * Linux distributions
> > * API compatibility for between all LTS revisions. API changes would be
> > limited to those required to fix defects or address security issues.
> >
> > An LTS release would have a twenty (20) month lifetime from the date the
> > release branch is cut. This support period allows up to two (2) months of
> > branch stabilization before initial release with a minimum of eighteen
> (18)
> > months of availability for deployment. LTS releases would have the
> > following support periods:
> >
> > * 0-14 months: backport all defect fixes in the scope of the LTS release
> > functionality; fix all blocker and critical priority defects identified
> in
> > the branch
> > * 14-20 months: backport only CVE fixes in the scope of the LTS release
> > functionality; fix all blocker priority defects in the branch
> >
> > Defect fixes that originate in an LTS branch will be pulled forward to
> > master only. Finally, an LTS branch should be release the fewest times
> > necessary to deliver fixes in a relatively timely manner. Therefore, LTS
> > releases will be triggered based on the number of pending of fixes and
> > their severity with no defect fix awaiting release more than forty-five
> > (45) days. CVE fixes would trigger an immediate release of an LTS branch.
> >
> >
>
> Is this going to be official ASF CloudStack releases following the
> necessary protocol of vote periods, binding votes etc. or will this be a
> community release by 3rd parties?
> I am asking now so that we are all on the same page here when we get to the
> first release.
>
>
> > Resourcing and Proposed Timeline
> > ===========================
> >
> > Broad community support is vital to guarantee the twenty (20) month
> > support period for each LTS branch. Given the ebbs and flows of
> > contribution and committer priorities, ShapeBlue will provide a release
> > manager, as well as, engineering support to fill any contribution gaps to
> > ensure that the community fulfills LTS commitments.
> >
> > In order to prepare for supporting LTS releases, we would need to
> complete
> > the following items:
> >
> > 1. All tools that do version number comparisons would be made aware of
> the
> > LTS versioning scheme
> > 2. Officially support running the management server on Java 8 since Java
> 7
> > has been EOL since last April [1] (i.e. compile to 1.7 with the Java 1.8
> > compiler and run on Java 1.8). Providing a 20-month support window on an
> > EOL JVM is an unacceptable security risk.
> > 3. Update the wiki and website to explain the new release cycle and help
> > users decide which release type suits their needs
> > 4. Define an initial test plan for LTS stabilization
> > 5. Agree on the definitions of ticket severities
> >
> > In order to address these items and start on a regular rhythm, I propose
> > that first LTS cycle begin on 1 July 2015. In the interim, we would
> > continue to ship critical bug fixes from the 4.5 release as this release
> > seems to be the most commonly deployed in the community.
> >
>
> 1 July 2016 I assume? :-)
>
>
> >
> > Together, the monthly and LTS release cycles address the needs of the
> > entire Apache CloudStack user community. I believe that the process
> > described in the proposal will yield releases that meet the needs of
> users
> > requiring release stability without adversely affecting the velocity of
> the
> > monthly release cycle.
> >
> >
>
> Huge +1.
> I understand that a lot of people want fast and rapid releases, but that
> does not work for everyone, me included. I'll most likely run LTS in
> production, but latest monthly in labs/testing.
>
>
>
> --
> Erik
>



-- 
Daan

Re: [PROPOSAL] LTS Release Cycle

Posted by Erik Weber <te...@gmail.com>.

On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <jo...@shapeblue.com>
wrote:

> Motivation
> ========
>
> The current monthly release cycle addresses the needs of users focused on
> deploying new functionality as quickly as possible. It does not address the
> needs of users oriented towards stability rather than new functionality.
> These users typically employ QA processes to comply with corporate policy
> and/or regulatory requirements. To maintain a growing, thriving community,
> we must address the needs of both user types. Therefore, I propose that we
> overlay a LTS release cycle onto the monthly release cycle to address the
> needs of stability-oriented users with minimal to no impact on the monthly
> release cycle. This proposed LTS release cycle has the following goals:
>
> * Prefer Stability to New Functionality: Deliver releases that only
> address defects and CVEs. This narrowly focused change scope greatly
> reduces the upgrade risk/operational impact and shorter internal QA cycles.
> * Reliable Release Lifetimes: Embracing a time-based release strategy, the
> LTS release cycle will provide users with a reliable support time frames.
> Users can use these time frames provide users with an 20 month window in
> which to plan upgrades.
> * Support Sustainability: With a defined end of support for LTS releases
> and a maximum of two (2) LTS releases under active maintenance at any given
> time, community members can better plan their commitments to release
> support activities. We also have a agreed upon policy for release
> end-of-life (EOL) to debate about continuing work on old releases.
>
> Proposed Process
> ==============
>
> LTS release branches will be cut twice year on 1 Jan and 1 July from the
> tag of the most recent monthly release. The branch will be named <base
> version>-LTS and each LTS release will be versioned in the form of <base
> version>-<LTS revision number>. For example, if we cut an LTS branch based
> on 4.7.0, the branch would be named 4.7.0-LTS and the version of the first
> LTS release would be 4.7.0-0, the second would be 4.7.0-1, etc. This
> release naming convention differentiates LTS and monthly releases,
> communicates the version on which the LTS release is based, and allows the
> maintenance releases for monthly releases without version number
> contention/conflict. Finally, like master, an LTS branch would be always
> deployable following its initial release. While it is unlikely that LTS
> users would deploy from the branch, the quality discipline of this
> requirement will benefit the long term stability of LTS releases. All PRs
> targeting an LTS would require two LGTMs in order to be merged.
>
> The following are the types of changes that would permitted and guarantees
> provided to users:
>
> * No features or enhancements would be backported to LTS release branches.
> * Database changes would be limited to those required to address the
> backported defect fixes.
> * Support for the release/version of the following components from the
> release on which the LTS is based throughout the entire release cycle:
> * MySQL/MariaDB
> * JDK/JRE
> * Linux distributions
> * API compatibility for between all LTS revisions. API changes would be
> limited to those required to fix defects or address security issues.
>
> An LTS release would have a twenty (20) month lifetime from the date the
> release branch is cut. This support period allows up to two (2) months of
> branch stabilization before initial release with a minimum of eighteen (18)
> months of availability for deployment. LTS releases would have the
> following support periods:
>
> * 0-14 months: backport all defect fixes in the scope of the LTS release
> functionality; fix all blocker and critical priority defects identified in
> the branch
> * 14-20 months: backport only CVE fixes in the scope of the LTS release
> functionality; fix all blocker priority defects in the branch
>
> Defect fixes that originate in an LTS branch will be pulled forward to
> master only. Finally, an LTS branch should be release the fewest times
> necessary to deliver fixes in a relatively timely manner. Therefore, LTS
> releases will be triggered based on the number of pending of fixes and
> their severity with no defect fix awaiting release more than forty-five
> (45) days. CVE fixes would trigger an immediate release of an LTS branch.
>
>

Is this going to be official ASF CloudStack releases following the
necessary protocol of vote periods, binding votes etc. or will this be a
community release by 3rd parties?
I am asking now so that we are all on the same page here when we get to the
first release.


> Resourcing and Proposed Timeline
> ===========================
>
> Broad community support is vital to guarantee the twenty (20) month
> support period for each LTS branch. Given the ebbs and flows of
> contribution and committer priorities, ShapeBlue will provide a release
> manager, as well as, engineering support to fill any contribution gaps to
> ensure that the community fulfills LTS commitments.
>
> In order to prepare for supporting LTS releases, we would need to complete
> the following items:
>
> 1. All tools that do version number comparisons would be made aware of the
> LTS versioning scheme
> 2. Officially support running the management server on Java 8 since Java 7
> has been EOL since last April [1] (i.e. compile to 1.7 with the Java 1.8
> compiler and run on Java 1.8). Providing a 20-month support window on an
> EOL JVM is an unacceptable security risk.
> 3. Update the wiki and website to explain the new release cycle and help
> users decide which release type suits their needs
> 4. Define an initial test plan for LTS stabilization
> 5. Agree on the definitions of ticket severities
>
> In order to address these items and start on a regular rhythm, I propose
> that first LTS cycle begin on 1 July 2015. In the interim, we would
> continue to ship critical bug fixes from the 4.5 release as this release
> seems to be the most commonly deployed in the community.
>

1 July 2016 I assume? :-)


>
> Together, the monthly and LTS release cycles address the needs of the
> entire Apache CloudStack user community. I believe that the process
> described in the proposal will yield releases that meet the needs of users
> requiring release stability without adversely affecting the velocity of the
> monthly release cycle.
>
>

Huge +1.
I understand that a lot of people want fast and rapid releases, but that
does not work for everyone, me included. I'll most likely run LTS in
production, but latest monthly in labs/testing.



-- 
Erik