I’m back online and will continue working on this as soon as I worked through
the many mails ;-)
Happy to be your RM together with Rajani!
Regards,
Remi
On 17 Jul 2015, at 17:04, sebgoa run...@gmail.commailto:run...@gmail.com
wrote:
Finally read the thread,
It seems to me that a way
Finally read the thread,
It seems to me that a way forward is to have Remi and Rajani RM 4.6 (which is
currently master).
The two of them can discuss and start RMing 4.6 (PR merge etc) and then we can
iterate on the wiki release scenario.
@Remi @Rajani, would that work for you and you ready
Rene, Remi, I read back the thread and have another answer on this for
you; The branch contains a point version number instead of a
x.y.z-SNAPSHOT, without the branch a revert commit must follow if we
vote them out. a branch can be simply neglected.
On Thu, Jul 2, 2015 at 4:46 PM, Remi Bergsma
While I like the ideas generally [1], some concerns and observations that I
wish could be considered;
- active contributor crunch:
we don’t have large number of active people working towards testing, fixing
bugs and release, and reviewing/merging PRs on *master*; this affects the
agility of
Hi Rajani,
Happy to hear we agree on the goal and on the release process. Also great you
want to join the RM effort!
What remains is a discussion about the maintenance. I think the difference in
our approaches, is that you say “commit to release branch, then bring it to
master” and I say the
: Re: [DISCUSS] Release principles for Apache CloudStack
I do not agree to backporting aka cherry picking. I prefer forward merges(tofu
scale) 4.4 to 4.5 to master etc.
That way, none of the changes will be missed and git branch --contains gives a
nice view of where all the changes went.
On Thu
in master.
best,
Raja
-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org]
Sent: Friday, July 3, 2015 8:00 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Release principles for Apache CloudStack
I do not agree to backporting aka cherry picking. I prefer forward
On 3 jul. 2015, at 09:21, sebgoa run...@gmail.com wrote:
On Jul 3, 2015, at 9:06 AM, Raja Pullela raja.pull...@citrix.com wrote:
Remi,
couple of questions on the branching part - when we take the Feature PR and
Feature is back in Master, feel like we are potentially destabilizing
Hi Rajani, all,
I do think we have the same goal in mind: no regression and no cherry-pick mess.
Just did some reading on tofu scale and see two issues:
- if it doesn't happen / isn't completed we'll have regression as we've seen
before. I want a working model that prevents regression by
On Fri, Jul 3, 2015 at 10:06 AM, Remi Bergsma r...@remi.nl wrote:
Hi Rajani, all,
I do think we have the same goal in mind: no regression and no cherry-pick
mess.
Just did some reading on tofu scale and see two issues:
- if it doesn't happen / isn't completed we'll have regression as we've
I agree to the goal. No regressions can be achieved either by cherry-picks
or merges. Both requires developers to agree to it and has equal
probability to miss.
The advantage in case of merge is, lets say you do a commit a1 to 4.5
branch and forget to merge to master. now, someone else did a2 and
Hi all,
We already agreed contributions should always go via a PR and require two
LGTM’s before we merge. Let me propose the next step on how I think we should
do release management for 4.6 and on.
I talked to several people over the past weeks and wrote this wiki article:
[mailto:r...@remi.nl]
Sent: 02 July 2015 17:17
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Release principles for Apache CloudStack
Hi all,
We already agreed contributions should always go via a PR and require two
LGTM’s before we merge. Let me propose the next step on how I think we should
and selectively merged back to x.y branch?
-Original Message-
From: Remi Bergsma [mailto:r...@remi.nl]
Sent: 02 July 2015 17:17
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Release principles for Apache CloudStack
Hi all,
We already agreed contributions should always go via
: [DISCUSS] Release principles for Apache CloudStack
Hi all,
We already agreed contributions should always go via a PR and require two
LGTM’s before we merge. Let me propose the next step on how I think we
should do release management for 4.6 and on.
I talked to several people over the past
Thanks! Appreciate it :-)
On 02 Jul 2015, at 13:51, Daan Hoogland daan.hoogl...@gmail.com wrote:
be sure you're backed
On Thu, Jul 2, 2015 at 1:46 PM, Remi Bergsma r...@remi.nl wrote:
Hi all,
We already agreed contributions should always go via a PR and require two
LGTM’s before we
Hi Remi
On 02.07.2015 13:46, Remi Bergsma wrote:
I talked to several people over the past weeks and wrote this wiki article:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
be sure you're backed
On Thu, Jul 2, 2015 at 1:46 PM, Remi Bergsma r...@remi.nl wrote:
Hi all,
We already agreed contributions should always go via a PR and require two
LGTM’s before we merge. Let me propose the next step on how I think we should
do release management for 4.6 and on.
I
On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma r...@remi.nl wrote:
Since the goal is a stable master, I’d say the bug fix should go to master
first.
Remi, this means that merge back of the branch makes no sense anymore.
--
Daan
Hi René,
The reason is that I tried to stay close to how it is done now so we could
reuse the scrips.
You do have a valid point, as indeed no commits are expected (nor should be
allowed) until the vote passes.
Pinging @dahn to ask if he knows of other reasons to use a branch for RC and if
I do not agree to backporting aka cherry picking. I prefer forward
merges(tofu scale) 4.4 to 4.5 to master etc.
That way, none of the changes will be missed and git branch --contains
gives a nice view of where all the changes went.
On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma r...@remi.nl
Hi Daan,
Indeed. I prefer committing to master first, as it will ensure everything ends
up there (unless some specific use cases). Currently, we have the risk of
forgetting to include a fix to a release branch back to master.
When we reverse it, some bug fix that should end up in the x.y
22 matches
Mail list logo
