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: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 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 <run...@gmail.com> wrote: > > On Oct 16, 2014, at 8:08 PM, Sheng Yang <sh...@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
