cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: merging versus cherry-picking
Date Fri, 17 Oct 2014 00:01:40 GMT
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