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 Thu, 16 Jul 2015 01:07:10 GMT
On Wed, Jul 15, 2015 at 7:45 PM, Roman Shaposhnik <> wrote:
> On Wed, Jul 15, 2015 at 4:34 PM, Chris Douglas <> wrote:
>> On Wed, Jul 15, 2015 at 4:21 PM, Roman Shaposhnik <> wrote:
>>> As long as there's a human being in the loop reviewing what's going into the
>>> repo I don't think I've got any issues with the process.
>> The ASF needs to establish provenance. It can't do that if a committer
>> pushes code that was posted to infrastructure owned by UCI. We need a
>> record of the patch from the contributor, not just the committer. -C
> My assessment of the situation is based on the workflow where whoever
> is pushing the commits into the repo is reviewing both committers and
> authors of every commit that goes in.
> If that's the case I see no material difference between the above and
> a committers pushing a patch contributed on JIRA by Jon Doe OR
> a Github Pull Request. Both acceptable practices within existing
> ASF projects.

I'll respectfully disagree, and I'll illustrate it with a real world example.

My employer, Citrix, wanted to operate a Gerrit instance for
CloudStack. This was rejected out of hand (and the main reason was
project independence - sending people to to submit
their patches hardly makes the project seem independent. But ignoring
that issue. This effectively means people would be doing all of the
development in a Citrix hosted git repo. A git repo that the
foundation does not control authz to, nor has access to push logs for.
We then lose all of the data in the push logs when commits are synced
from the Citrix repo to the ASF repo. And to boot, we generate what
are essentially dummy records in the process of shipping data over.

I understand that git is a DVCS, but by mirroring the commit content
from one repo to the ASF (albeit via a committer middleman), we
largely make the push records[1] pointless. That turns our copy of the
repository into the equivalent of a github fork. It has all of the
commit history, but none of the real provenance information. I
understand that as a DVCS, the idea of a canonical repository is
strange and foreign, and git usage patterns typically involve
situations where they ignore push records themselves, but I am at a
loss as to how we preserve useful records when we are just syncing
stuff from a Gerri-managed repo.


[1] Just to be perfectly clear, because frankly, I didn't understand
it when people talked to me about it initially - the push logs have
nothing to do with commit log. Push logs are tied to the authorization
tool, and are not stored in the repository.  Here's the push logs for

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

View raw message