incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Farrell <>
Subject Re: Podling request: Gerrit
Date Wed, 15 Jul 2015 01:51:36 GMT
Hey Till
All commits must occur against the ASF codebase and can not be mirrored
over from a different location (this includes Github, Gerrit, etc.). This
is a mandate that has come from the board level and is not a negotiable

Gerrit has been discussed many times before and each time the answer has
been that without people to help maintain the service and until Gerrit can
be used as only a review tool and not require controlling the primary
codebase and resulting merge that it will not be an viable option for the
ASF's use.

We are working to see what we can do to help ease some of the pain with
pull requests, but at this time the tooling available is as stated
previously in this thread. Infra is always happy to take suggestions and
any ideas and we are always looking for volunteers that are interested in
lending a hand and helping improve our ecosystem for all projects. If you
have any questions please let me know


On Tue, Jul 14, 2015 at 8:08 PM, Till Westmann <> wrote:

> On 14 Jul 2015, at 15:31, David Nalley wrote:
>  On Tue, Jul 14, 2015 at 1:14 AM, Ian Maxon <> wrote:
>>  We use Gerrit as
>>> a tool to do code reviews and to organize the commits, as well as to
>>> facilitate easy testing. However that's all it's used for- we still
>>> clone from repositories that come downstream from ASF, not the other
>>> way around. I'd be interested to understand how this would be
>>> considered any different than what is done with Github Pull Requests.
>> So GH PR have a subtle distinction (at least in the way that they are
>> handled at the ASF). Projects can't merge pull requests into the repo
>> at github. Non-committers see a workflow that is the Github workflow,
>> because that's very familiar, and lowers the barrier to contribution.
>> Committers, however, have a very different workflow than the folks who
>> typically review and close pull requests on github. They have to take
>> the patch [1], and merge it into the canonical repository at the ASF,
>> which then appears in the github repository because of the mirror
>> process.  This stops the problem of diverging codebases that you are
>> currently experiencing, calls to rewrite history to align the ASF repo
>> with the external repo, etc.
> As Ian indicated AsterixDB's process also requires manual interaction of
> a committer. The current steps are now documented on the website [2].
>  There are some other problems, that aren't necessarily as worrisome,
>> but should be something to consider. First, you're relying on a third
>> party to provide that resource. That's not inherently a problem, but
>> we have a number of examples of projects using external tools and
>> those being shut down or phased out which causes tremendous disruption
>> to projects. It's also at the old project's home, which might cause
>> some folks to question whether the project is truly independent, or
>> not.
> In my view Gerrit is "just" a tool that the AsterixDB community chose
> to keep when starting the incubation process. It is is non-essential and
> has been used by developers from different organizations before the
> incubation started. But I think that its use was and is very beneficial
> to the project.
> When we started incubation it seemed to us, that keeping the existing
> tool would be a good idea as it
> a) allows for a smoother transition and
> b) would not put additional requirements on the ASF infrastructure.
> However, I do agree that a shut down of the service (which seems very
> unlikely at the current point in time) could be a disruption to the
> project. So it might be better to run this tool on the ASF
> infrastructure.
> Should we pursue this?
> Or is it acceptable to keep the tool on external hardware for now?
> Or do you see fundamental issues with AsterixDB's use of Gerrit?
> Thanks,
> Till
>  [1]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message