it to master through PR only
On Thu, Jul 9, 2015 at 12:04 PM, Rohit Yadav
wrote:
>
> On 09-Jul-2015, at 2:56 pm, Daan Hoogland wrote:
>
> I like the idea but think that 72 hours is way to short
>
>
> I think 72 hours (note: no counting weekends) should be good enough,
>
On Thu, Jul 9, 2015 at 12:04 PM, Rohit Yadav
wrote:
>
> On 09-Jul-2015, at 2:56 pm, Daan Hoogland wrote:
>
> I like the idea but think that 72 hours is way to short
>
>
> I think 72 hours (note: no counting weekends) should be good enough,
> which is the window for our release/vote process as w
On 09-Jul-2015, at 2:56 pm, Daan Hoogland
mailto:daan.hoogl...@gmail.com>> wrote:
I like the idea but think that 72 hours is way to short
I think 72 hours (note: no counting weekends) should be good enough, which is
the window for our release/vote process as well. We can increase this to
perh
On Thu, Jul 9, 2015 at 10:51 AM, Rohit Yadav
wrote:
>
> On 09-Jul-2015, at 2:14 pm, Rohit Yadav wrote:
>
> - This seems to be already failing, under the Apache way IMO there is no
> way we can enforce and ensure that at least two people would review any and
> every PR. There are already a growin
On 09-Jul-2015, at 2:14 pm, Rohit Yadav
mailto:rohit.ya...@shapeblue.com>> wrote:
- This seems to be already failing, under the Apache way IMO there is no way we
can enforce and ensure that at least two people would review any and every PR.
There are already a growing number of open PRs that w
On 07-Jul-2015, at 1:09 pm, sebgoa mailto:run...@gmail.com>>
wrote:
The PR should not be squashed until it's reviewed and accepted.
I am only arguing for squashing it when it is accepted and before merge.
For now, I would love for us to focus on the 2 LGTM and green tests (as much as
we can g
es change,
>>> then I commit the change again.
>>>
>>> Now, think about the PR. It will contain 2 commits: 1 with the formatting
>>> changes only; and a second commit with 3 lines change.
>>>
>>> Would you like to see it quashed and all messe
the PR. It will contain 2 commits: 1 with the formatting
>>> changes only; and a second commit with 3 lines change.
>>>
>>> Would you like to see it quashed and all messed up? It would be very
>>> difficult to review.
>>>
>>> That’s just a simple e
w.
>>
>> That’s just a simple example.
>>
>> Cheers,
>> Wilder
>>
>>> On 02 Jul 2015, at 07:22, Rajesh Battala wrote:
>>>
>>> +1 for squashing commit
>>>
>>> -Original Message-
>>> From: John Burwel
]
Sent: 02 July 2015 19:35
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] Commit to master through PR only
Wilder,
In the grand scheme of the entire project history (e.g. reading git log), why
do I care about these discrete operations? In six months (or long), I (as the
consumer of
burw...@shapeblue.com]
>> Sent: Thursday, July 2, 2015 12:14 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Commit to master through PR only
>>
>> All,
>>
>> I think we should stick to 2 votes per PR. Defining types of PRs becomes
&g
> Cheers,
> Wilder
>
>> On 02 Jul 2015, at 07:22, Rajesh Battala wrote:
>>
>> +1 for squashing commit
>>
>> -Original Message-
>> From: John Burwell [mailto:john.burw...@shapeblue.com]
>> Sent: Thursday, July 2, 2015 12:14 AM
>> To: de
Daan,
Having worked in an environment where PRs are required for all merges, tooling
is only way to ensure it is followed without creating a tremendous human
burden. The tooling is not difficult to implement (and there are a number of
options beside the one I suggested), and reduces (or elimin
wrote:
>>
>> +1 for squashing commit
>>
>> -Original Message-
>> From: John Burwell [mailto:john.burw...@shapeblue.com]
>> Sent: Thursday, July 2, 2015 12:14 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Commit to master through PR only
&
[mailto:john.burw...@shapeblue.com]
> Sent: Thursday, July 2, 2015 12:14 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Commit to master through PR only
>
> All,
>
> I think we should stick to 2 votes per PR. Defining types of PRs becomes
> difficult bor
+1 for squashing commit
-Original Message-
From: John Burwell [mailto:john.burw...@shapeblue.com]
Sent: Thursday, July 2, 2015 12:14 AM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] Commit to master through PR only
All,
I think we should stick to 2 votes per PR. Defining types
> -Original Message-
> From: John Burwell [mailto:john.burw...@shapeblue.com]
> Sent: Thursday, July 2, 2015 12:14 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Commit to master through PR only
>
> All,
>
> I think we should stick to 2 votes per
I do the same Erik. Sometimes I merge the changes from the authors branch
directly without creating a local copy (using the command mentioned in the
pull request mail).
+1 on 2 manual reviews per PR irrespective of how trivial it is.
-1 on squashed commits. If the author thinks that the change de
On Wed, Jul 1, 2015 at 7:48 PM, Rohit Yadav
wrote:
> Hi,
>
> > On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen wrote:
> >
> > A few of us are in Amsterdam at DevOps days. We are chatting about
> release management procedure.
> > Remi is working on a set of principles that he will put on the wiki
On Wed, Jul 1, 2015 at 8:44 PM, John Burwell wrote:
> All,
>
> I think we should stick to 2 votes per PR. Defining types of PRs becomes
> difficult bordering on the arbitrary — adding a process complexity and the
> potential to start debating if a particular PR is one type or another.
agree
>
I'm afraid I don't agree on some of points here, Rohit.
On Wed, Jul 1, 2015 at 7:48 PM, Rohit Yadav wrote:
...
> Some suggestions and comments to improve PR reviewing/merging:
>
> - Let's merge the PR commits in a fast forward way instead of doing a branch
> merge that introduces frivolous merg
All,
I think we should stick to 2 votes per PR. Defining types of PRs becomes
difficult bordering on the arbitrary — adding a process complexity and the
potential to start debating if a particular PR is one type or another.
I agree regarding the fast forward, and feel that all PRs should squas
Hi,
> On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen wrote:
>
> A few of us are in Amsterdam at DevOps days. We are chatting about release
> management procedure.
> Remi is working on a set of principles that he will put on the wiki to start
> a [DISCUSS].
>
> However to get started on the righ
On Wed, Jul 1, 2015 at 3:39 AM, sebgoa wrote:
>
> On Jul 1, 2015, at 9:35 AM, Wilder Rodrigues
> wrote:
>
>> Nice!
>>
>> I spent couple of hours this morning to review a few PRs.
>>
>> But we still have too many of them and not many people reviewing/testing,
>> which makes the process a bit slo
On Jul 1, 2015, at 9:35 AM, Wilder Rodrigues
wrote:
> Nice!
>
> I spent couple of hours this morning to review a few PRs.
>
> But we still have too many of them and not many people reviewing/testing,
> which makes the process a bit slow.
>
I expect this week to get slow. It's July 4th week
Nice!
I spent couple of hours this morning to review a few PRs.
But we still have too many of them and not many people reviewing/testing, which
makes the process a bit slow.
>From the guys who usually review PRs, who is currently on holidays?
Cheers,
Wilder
> On 29 Jun 2015, at 11:27, sebgoa
Ok we are on,
Starting today, commit to master through PR only.
2 LGTM needed for merge.
If Travis fails, we can still merge given a good explanation of why (since
travis has issues once in a while).
I will keep an eye on commit, at least once a day, and ping the list if I see a
commit that wen
Let’s do it!
Starting tomorrow we’ll commit to master through PR only (as described below),
and we’ll evaluate this at Sept 30, 2015.
I’ll put a reminder in my schedule to start the thread.
Regards,
Remi
> On 26 jun. 2015, at 23:10, Daan Hoogland wrote:
>
> date := 2015-09-30 ???
>
> On Fr
date := 2015-09-30 ???
On Fri, Jun 26, 2015 at 9:54 PM, David Nalley wrote:
> On Thu, Jun 25, 2015 at 10:38 AM, Sebastien Goasguen wrote:
>> Folks,
>>
>> A few of us are in Amsterdam at DevOps days. We are chatting about release
>> management procedure.
>> Remi is working on a set of principles
On Thu, Jun 25, 2015 at 10:38 AM, Sebastien Goasguen wrote:
> Folks,
>
> A few of us are in Amsterdam at DevOps days. We are chatting about release
> management procedure.
> Remi is working on a set of principles that he will put on the wiki to start
> a [DISCUSS].
>
> However to get started on
That's what the _Extended suffix i added means :)
On Fri, Jun 26, 2015 at 3:15 PM, Daan Hoogland
wrote:
> On Fri, Jun 26, 2015 at 3:13 PM, Rafael Fonseca
> wrote:
> > Or if we really want the extra overhead:
> >
> > ( Green_Travis && 2LGTM) || ( Red_Travis_false_positive &&
> 3LGTM_Extended)
>
On Fri, Jun 26, 2015 at 3:13 PM, Rafael Fonseca wrote:
> Or if we really want the extra overhead:
>
> ( Green_Travis && 2LGTM) || ( Red_Travis_false_positive && 3LGTM_Extended)
or
( Green_Travis && 2LGTM) || ( Red_Travis_false_positive &&
2LGTM_Extended && justification in writing)
that was th
I did not mean to imply that you were saying red travis was fine :)
Just that it was requiring same number of people to look at it as the green
travis, of course no one should put in a LGTM on a failed travis without
looking at what the travis output was :)
Even the fuzzy stuff can be booleanized,
I said that red travis is requiring extra explanation by the LGTMers
to justify overrinding travis as an alternative to green travis. Not
that red travis is fine.
your logic is too boolean, not fuzzy enough
On Fri, Jun 26, 2015 at 2:42 PM, Rafael Fonseca wrote:
> I agree with Daan also, but ther
I agree with Daan also, but there's a conflict here..
Initial suggestion:
( Green_Travis && 2LGTM)
Daan suggested:
( Red_Travis && 2LGTM)
Which would make for:
( Green_Travis && 2LGTM) || ( Red_Travis && 2LGTM)
Or apply boolean logic to remove redundant parameters:
(2LGTM)
This would compl
Hi
On 25.06.2015 16:38, Sebastien Goasguen wrote:
> - Only commit through PR will land on master (after a minimum of 2 LGTM and
> green Travis results)
> - Direct commit will be reverted
> - Any committer can merge the PR.
That's the way I used to work. That's fine! :)
One technical benefit is
Hi Seb,
Love the idea, let’s do it!
Cheers,
Funs
> On 26 Jun 2015, at 10:14, Erik Weber wrote:
>
> On Thu, Jun 25, 2015 at 4:38 PM, Sebastien Goasguen
> wrote:
>
>> Folks,
>>
>> A few of us are in Amsterdam at DevOps days. We are chatting about release
>> management procedure.
>> Remi is w
On Thu, Jun 25, 2015 at 4:38 PM, Sebastien Goasguen
wrote:
> Folks,
>
> A few of us are in Amsterdam at DevOps days. We are chatting about release
> management procedure.
> Remi is working on a set of principles that he will put on the wiki to
> start a [DISCUSS].
>
> However to get started on th
Clean and simple, Sebastien. I like that. :)
Concerning Travis, I’m with Daan and Remi: in case of a red Travis run, a good
analysis on the results is needed before saying no.
Let’s make ACS more awesome! ;)
Cheers,
Wilder
> On 25 Jun 2015, at 22:03, Remi Bergsma wrote:
>
> Good point Daan,
Good point Daan, I like it!
2015-06-25 16:49 GMT+02:00 Daan Hoogland :
> I still don't think travis is reliable enough to give a definite 'no'.
> Two LGTMs is fine and a good argument if travis is red on why this is
> not a problem for this case.
>
> On Thu, Jun 25, 2015 at 4:47 PM, Rafael Fonsec
Travis is still not there but it's already pretty close hehe.. hope to make
it 100% soon :)
On Thu, Jun 25, 2015 at 4:49 PM, Daan Hoogland
wrote:
> I still don't think travis is reliable enough to give a definite 'no'.
> Two LGTMs is fine and a good argument if travis is red on why this is
> not
I still don't think travis is reliable enough to give a definite 'no'.
Two LGTMs is fine and a good argument if travis is red on why this is
not a problem for this case.
On Thu, Jun 25, 2015 at 4:47 PM, Rafael Fonseca wrote:
> Couldn't make it either :'(
>
> I think it's a very sound idea in prin
Couldn't make it either :'(
I think it's a very sound idea in principle, but afraid waiting for two
LGTM might slow things down even further... up to the majority vote i guess
it's a good principle either way :)
On Thu, Jun 25, 2015 at 4:41 PM, Wido den Hollander wrote:
> -BEGIN PGP SIGNED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/25/2015 04:38 PM, Sebastien Goasguen wrote:
> Folks,
>
> A few of us are in Amsterdam at DevOps days. We are chatting about
> release management procedure. Remi is working on a set of
> principles that he will put on the wiki to start a [DISCU
Folks,
A few of us are in Amsterdam at DevOps days. We are chatting about release
management procedure.
Remi is working on a set of principles that he will put on the wiki to start a
[DISCUSS].
However to get started on the right track. I would like to propose the
following easy step:
Startin
45 matches
Mail list logo
