to master through PR only
On Thu, Jul 9, 2015 at 12:04 PM, Rohit Yadav rohit.ya...@shapeblue.com
wrote:
On 09-Jul-2015, at 2:56 pm, Daan Hoogland 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
On 07-Jul-2015, at 1:09 pm, sebgoa run...@gmail.commailto: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
On 09-Jul-2015, at 2:14 pm, Rohit Yadav
rohit.ya...@shapeblue.commailto: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
On Thu, Jul 9, 2015 at 10:51 AM, Rohit Yadav rohit.ya...@shapeblue.com
wrote:
On 09-Jul-2015, at 2:14 pm, Rohit Yadav 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
On 09-Jul-2015, at 2:56 pm, Daan Hoogland
daan.hoogl...@gmail.commailto: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
On Thu, Jul 9, 2015 at 12:04 PM, Rohit Yadav rohit.ya...@shapeblue.com
wrote:
On 09-Jul-2015, at 2:56 pm, Daan Hoogland 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
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
, 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 bordering on the arbitrary — adding a process complexity and the
potential to start debating
: [PROPOSAL] Commit to master through PR only
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
]
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
...@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 bordering on the arbitrary — adding a process complexity
[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 bordering on the arbitrary — adding
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 of PRs becomes
difficult bordering
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
...@citrix.com 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
All,
I think we should stick to 2
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
On Wed, Jul 1, 2015 at 8:44 PM, John Burwell john.burw...@shapeblue.com 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
On Wed, Jul 1, 2015 at 7:48 PM, Rohit Yadav rohit.ya...@shapeblue.com
wrote:
Hi,
On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen run...@gmail.com 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
I'm afraid I don't agree on some of points here, Rohit.
On Wed, Jul 1, 2015 at 7:48 PM, Rohit Yadav rohit.ya...@shapeblue.com 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
On Wed, Jul 1, 2015 at 3:39 AM, sebgoa run...@gmail.com wrote:
On Jul 1, 2015, at 9:35 AM, Wilder Rodrigues wrodrig...@schubergphilis.com
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,
Hi,
On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen run...@gmail.com 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
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
On Jul 1, 2015, at 9:35 AM, Wilder Rodrigues wrodrig...@schubergphilis.com
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
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
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
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 daan.hoogl...@gmail.com wrote:
date :=
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 r...@remi.nl wrote:
Good
On Thu, Jun 25, 2015 at 4:38 PM, Sebastien Goasguen run...@gmail.com
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
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
date := 2015-09-30 ???
On Fri, Jun 26, 2015 at 9:54 PM, David Nalley da...@gnsa.us wrote:
On Thu, Jun 25, 2015 at 10:38 AM, Sebastien Goasguen run...@gmail.com wrote:
Folks,
A few of us are in Amsterdam at DevOps days. We are chatting about release
management procedure.
Remi is working on
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
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 completely
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 rsafons...@gmail.com wrote:
I agree with
Good point Daan, I like it!
2015-06-25 16:49 GMT+02:00 Daan Hoogland daan.hoogl...@gmail.com:
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
-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 [DISCUSS].
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 rsafons...@gmail.com wrote:
Couldn't make it either :'(
I think it's a very
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:
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 daan.hoogl...@gmail.com
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
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 w...@widodh.nl wrote:
39 matches
Mail list logo
