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
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
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
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
@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
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;
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
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
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
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
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
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
, 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.
> 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
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
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)
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
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
+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
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,
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
21 matches
Mail list logo