-Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: 17 October 2014 01:02
> To: dev@cloudstack.apache.org
> Subject: Re: merging versus cherry-picking
>
> I think this needs it's own thread as a [PROPOSAL] So a couple of comments:
>
> 1. I think we
parts individually, rather than
waiting for everything to be in place before doing anything.
--
Stephen Turner
-Original Message-
From: David Nalley [mailto:da...@gnsa.us]
Sent: 17 October 2014 01:02
To: dev@cloudstack.apache.org
Subject: Re: merging versus cherry-picking
I think this
I think this needs it's own thread as a [PROPOSAL]
So a couple of comments:
1. I think we need to do things in a uniform way. Having patches
committed directly, having patches hit RB and having patches hit GH is
fail.
2. I think we should gate patches, even from committers. I'd
personally like to
tt" wrote:
>
>> +1 to Sebastians proposal
>>
>>
>> Kind Regards
>> Giles
>>
>> D: +44 20 3603 0541 | M: +44 796 111 2055
>> giles.sir...@shapeblue.com
>>
>>
>>
>>
>> -Original Message-
>> From: Rohit
> >
> >
> >
> >
> > -Original Message-
> > From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> > Sent: 16 October 2014 11:58
> > To: dev@cloudstack.apache.org
> > Subject: Re: merging versus cherry-picking
> >
> > Hi,
&g
796 111 2055
>> giles.sir...@shapeblue.com
>>
>>
>>
>>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: 16 October 2014 11:58
>> To: dev@cloudstack.apache.org
>> Subject: Re: merging versus cherry-pi
D: +44 20 3603 0541 | M: +44 796 111 2055
> giles.sir...@shapeblue.com
>
>
>
>
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: 16 October 2014 11:58
> To: dev@cloudstack.apache.org
> Subject: Re: merging versus cherry-picking
&
+1 to Sebastians proposal
Kind Regards
Giles
D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com
-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: 16 October 2014 11:58
To: dev@cloudstack.apache.org
Subject: Re: merging versus cherry
+1 on merging(and the proposal).
Unlike the belief that merging adds to dev time it actually makes life
easier to track a commit (after all, it has the same number of commands and
the same conflicts as cherry-pick :) )
We should also define merge strategy for LTS(4.3 and 4.4) branches.
~Rajani
Hi,
On 16-Oct-2014, at 3:32 pm, sebgoa wrote:
> Proposal:
>
> All commits come through github PR, *even* for committers. We declare a
> moratorium period (agreed suspension of activity) during which direct commit
> to master is forbidden.
> Only the master RM is allowed to merge PR in mast
On Thu, Oct 16, 2014 at 11:34 AM, Daan Hoogland
wrote:
...
> I will do a test merge-back of 4.5 to master to see how big the damage is.
>
So I did locally and found:
commit 148efbb73f0e084614eff62f48ea9fa964c64da8
Merge: 1f8cf0b 420d4e0
Author: Daan Hoogland
Date: Thu Oct 16 12:29:37 20
+1
On Thu, Oct 16, 2014 at 12:02 PM, sebgoa wrote:
>
> On Oct 16, 2014, at 11:34 AM, Daan Hoogland
> wrote:
>
> Proposal:
>
> All commits come through github PR, *even* for committers. We declare a
> moratorium period (agreed suspension of activity) during which direct
> commit to maste
On Oct 16, 2014, at 11:34 AM, Daan Hoogland wrote:
> H,
>
> I noticed a lot of commits on master and 4.5 without any links between
> them. These could have all been committed on 4.5 and merged back into
> master leaving a trail of prove that the same code is in both branches.
>
> It hurts to s
13 matches
Mail list logo
