incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Podling request: Gerrit
Date Tue, 14 Jul 2015 01:00:33 GMT
On Mon, Jul 13, 2015 at 7:24 PM, Jochen Wiedmann
<> wrote:
> Hi,
> I am writing as one of the Mentors of the AsterixDB podling.
> It recently came to my attention, that there are, in fact, multiple
> Git repositories, which are used by the project, one of them being
> located externally of the ASF. I understand the structure to be like
> this:

This is a severe problem and needs to be rectified promptly.
How are commits migrating from the external repository to the ASF repository?
We typically end up missing provenance information that is important
in blind mirroring of content.

>   +--------------+  Commits   +------------------+  Mirrrors
> +----------------+
>    |  Gerrit      | --------------> | Git (External) | ------------->
> | Git (ASF)    |
>    +-------------+                    +------------------+
>      +----------------+
> The structure is made like this, because the project members desire
> that no commits can enter without a review, which is done in Gerrit. [2]
> (In the past, this was ensured by a commit hook in the external
> repository. That commit hook possibly still exists, but it doesn't
> prevent
> code to enter the ASF repository directly without a review. This lack
> of security is currently discussed by the podlings project members.)
> I understand the desire, and, to me, it makes sense. OTOH,  I suspect
> that this issue might affect a successful incubation. Hence this mail.

Agreed. This needs to be rectified rapidly.

> As Git is slowly gaining ground within the ASF, I'd suggest that a
> possible resolution might be to have a Gerrit instance within the ASF.
> Given how Github pull requests are already discussed by many projects,
> I can imagine that many projects would like to adopt a similar policy.

Git is very widely used - slightly over 1/2 of the active projects at
the ASF are using it now as their primary VCS.

That said, we've explored gerrit a number of times, most recently in
December. Just for frame of reference, I was very much in favor of
Gerrit. I thought that there were a number of projects who also wanted
it - but many of those changed their mind over time. In the end we
discovered that there are a number of challenges:

First, Gerrit wants what is best described as exclusive access to git
repositories. It tends to want them on a local filesystem, and
essentially acting as gatekeeper for commits. This isn't inherently a
problem if you have all repos treated this way. But since we don't
have all projects wanting
Second: Gerrit wants every patch author authenticated against a common
authn backend. This would mean folks would need accounts in LDAP. When
we explored this last our LDAP infrastructure was incapable of what
would have been an explosive growth in number of accounts and
authentication requests. We've since made the infrastructure much more
robust and resilient, but deploying gerrit would essentially require
us to have a self-service account creation service, and that's a lot
of work.

At the moment, Infrastructure doesn't see enough demand from projects
requesting Gerrit to make the tremendous investment required. We've
also noticed a number of trends in projects who were interested in

The oldest strategy is from Hadoop, and they have every patch
submitted to Jira. Every patch is automatically detected, and has a
pre-commit test job run, with Jenkins reporting to Jira the results of
the tests.

We have Reviewboard[0], which is gerrit-like, without the problems
listed above.

More recently, we have folks making heavy use of github pull requests.
and there are two primary technologies that are being seen there.
1. Github pull request builder: Jenkins watches for pull requests
against the GH mirror of the repo, and automatically picks up the job,
and then reports the success or failure of that job in the pull

2. TravisCI - The ASF has a paid account with TravisCI and has 30
concurrent builders. Like the Github Pull Request Builder, it watches
for pull requests against a repository and then runs tests, and then
reports against the pull request. [2]

Obviously, there's no automatic merge, or even technical enforcement.
However, most projects are able to use social enforcement (and reverts
if necessary) to ensure that folks aren't committing directly; and
automatic merges would be disallowed anyway since a committer needs to
make an explicit decision to commit.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message