> 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.
The push logs are intended to determine the committer either who authored the contribution or is taking responsibility for it if it's not authored by a committer, right? If that's the case then the push logs do show what's going on lately in terms of provenance, since we adopted the new procedure of having committers individually submit changes which they own. For example this line from the push log: [Fri May 22 23:41:08 2015] refs/heads/master 7de6f4eb80 -> b9611bb9ab mhubail@http.98.164.231.216 Murtadha did indeed author this commit. -Ian On Wed, Jul 15, 2015 at 6:07 PM, David Nalley <da...@gnsa.us> wrote: > On Wed, Jul 15, 2015 at 7:45 PM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: >> On Wed, Jul 15, 2015 at 4:34 PM, Chris Douglas <cdoug...@apache.org> wrote: >>> On Wed, Jul 15, 2015 at 4:21 PM, Roman Shaposhnik <ro...@shaposhnik.org> >>> 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 gerrit.citrix.com 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. > > --David > > [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 > AsterixDB. > https://git-wip-us.apache.org/logs/asf/incubator-asterixdb.git > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
