cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Turner <Stephen.Tur...@citrix.com>
Subject RE: merging versus cherry-picking
Date Mon, 20 Oct 2014 11:25:27 GMT
I am +1 on using github.

I am +1 on all code changes being reviewed by a committer other than the author, as well as
undergoing some automated CI testing, before the pull request is merged.

I am +0 on only the master RM merging the pull request. I don't want the author to push the
code, but I think the code reviewer could do this; in practice the RM will not be able to
review everything again so is likely to rubber-stamp the results of the code review / automated
testing. But I could live with the master RM doing it for the moment.

I am +1 on moving ahead with any of these parts individually, rather than waiting for everything
to be in place before doing anything.

-- 
Stephen Turner


-----Original Message-----
From: David Nalley [mailto:david@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 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 see ALL code
pass a comprehensive testing regimen, as well as be individually reviewed by a committer.
That said - I'd rather not let the perfect be the enemy of the good. Some testing is better
than none.

On Thu, Oct 16, 2014 at 3:23 PM, sebgoa <runseb@gmail.com> wrote:
>
> On Oct 16, 2014, at 8:08 PM, Sheng Yang <sheng@yasker.org> wrote:
>
>> I totally agree that we should have some staging tree for this 
>> purpose. But I would prefer deploying gerrit on this rather than 
>> using github. Also, using gerrit would make it possible to host our 
>> own Jenkins instance for testing, rather than depends on TravisCI 
>> which is very limited and shared across all the apache projects as I heard.
>
> Ok so looks like you are +1 for the general direction.

I also agree with this general direction.

>
> This is going to be a several steps process. While gerrit may end up 
> being the solution, right now it would require finding infra, 
> installing software, learning it for those who have not used it yet 
> etc…
>

I also have a preference for something more full featured than what we get with GH PR and
Travis CI - but frankly it's still better than what we have now. It might be worthwhile to
look into [1] which might allow us to use our existing Jenkins instance in the short term.
I know that Brooklyn is already using this service, and perhaps others. Gerrit is far more
full featured - and I can certainly see us wanting that (as well as a number of other communities
at the ASF.

> Moving to github PR with a moratorium on master and release branch is only a matter of
agreement that will make us adopt new commit habits. there is no change of infra/software
needed, hence an *easy* step, we just needs +1. Once we get to a better state of affairs we
can improve our infra and processes with other soft.
>
>>

So moratorium on unreviewed/untested patches = good. Is there a community aspect to people
effectively working in forks of our code base in isolation rather than in feature branches
in our main code base? (I ask because the easiest method for using GH PR is to use your own
fork of the repo. We could have contribs pushed to a feature branch still)


[1] https://blogs.apache.org/infra/entry/github_pull_request_builds_now
Mime
View raw message