like you comments Stephen +1
Daan On Mon, Oct 20, 2014 at 1:25 PM, Stephen Turner <stephen.tur...@citrix.com> wrote: > 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 > -- Daan
