Re: [PROPOSAL] LTS Release Cycle

2016-03-13 Thread John Burwell
Rene, I apologize for lag in my reply — I have been a bit consumed by the $dayjob lately. At any given time, the two most recent LTS releases receive full support (back port of blocker/critical fixes + CVE patches). The oldest LTS release only receives CVE patches. Given the infrequency of

Re: [PROPOSAL] LTS Release Cycle

2016-02-08 Thread Rene Moser
John, Something is not clear to me about the frequency of new LTS releases and support time range. You wrote in the proposal, that we branch off for a new LTS version 2 times a year, but only 2 LTS versions will in active maintained at any time, but supported for 20 months. This conflicting in

Re: [PROPOSAL] LTS Release Cycle

2016-02-02 Thread John Burwell
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

Re: [PROPOSAL] LTS Release Cycle

2016-01-20 Thread Daan Hoogland
peblue.com> > > > > > > -Original Message- > From: ilya [mailto:ilya.mailing.li...@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 stri

Re: [PROPOSAL] LTS Release Cycle

2016-01-20 Thread Remi Bergsma
@cloudyangus<tel:@cloudyangus> > >e: paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com>| > w: www.shapeblue.com<http://www.shapeblue.com> > > > > > >-Original Message- >From: ilya [mailto:ilya.mailing.li...@gmail

Re: [PROPOSAL] LTS Release Cycle

2016-01-20 Thread Rohit Yadav
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;

Re: [PROPOSAL] LTS Release Cycle

2016-01-20 Thread Daan Hoogland
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

RE: [PROPOSAL] LTS Release Cycle

2016-01-20 Thread Paul Angus
From: Remi Bergsma [mailto:rberg...@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 las

Re: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread Nux!
t;dev@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 <john.burw...@shapeblue.com> > wrote: > >> In terms of the merge strategy, nothing about the current pr

Re: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread Remi Bergsma
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

Re: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread Jeff Hair
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 wrote: > On a certain night when a release had been cut and there was some worry > about a

Re: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread Daan Hoogland
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 wrote: > Maybe require all cherry-picks to use the -x

RE: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread Paul Angus
, 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.

Re: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread ilya
> 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

Re: [PROPOSAL] LTS Release Cycle

2016-01-19 Thread John Burwell
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

Re: [PROPOSAL] LTS Release Cycle

2016-01-18 Thread John Burwell
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)

Re: [PROPOSAL] LTS Release Cycle

2016-01-18 Thread John Burwell
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

Re: [PROPOSAL] LTS Release Cycle

2016-01-18 Thread Daan Hoogland
On Tue, Jan 19, 2016 at 4:20 AM, John Burwell 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

Re: [PROPOSAL] LTS Release Cycle

2016-01-16 Thread Daan Hoogland
+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

[PROPOSAL] LTS Release Cycle

2016-01-15 Thread John Burwell
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

Re: [PROPOSAL] LTS Release Cycle

2016-01-15 Thread ilya
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,

Re: [PROPOSAL] LTS Release Cycle

2016-01-15 Thread Erik Weber
On Fri, Jan 15, 2016 at 7:48 PM, 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