So I think the issue here is that with the sync process, there's no direct ASF committer mediation on the actual pushing of commits into the canonical repo - in practice, this'll probably never be a problem, but the foundation's got to think about and prepare for the worst case. It's paranoid, sure, but necessary by ASF policy. The approach we've done in jclouds does involve a bit of extra work (doing the actual merge/cherry-pick from a pull request on our local repos and then pushing from there to the ASF repo) but it does avoid any possible problems caused by something like a security breach at GitHub resulting in malicious users getting push/pull rights to the GitHub repos and making commits/merging commits that aren't actually approved by the committers.
It's a compromise, but being an ASF project means you have to make some compromises compared to what you can do as an independent project. A. On Wed, Jun 18, 2014 at 11:02 AM, Joe Schaefer <[email protected]> wrote: > In the ASF REQUIRED process, WE HAVE RECORDS TO PROVE WHO > ADDED EVERY LINE OF CODE TO THE REPO. In the usergrid process, > we don't- maybe github does, maybe they don't. In any case that doesn't > matter, nor does the above requirement depend on Dave's understanding > of the underlying rationale behind it. > > You have your orders folks. They have been approved at every level of > this org. When can we expect a return to compliance? > > > > On Wednesday, June 18, 2014 1:57 PM, Dave <[email protected]> wrote: > > > > On Wed, Jun 18, 2014 at 1:00 PM, Joe Schaefer <[email protected]> > wrote: > > No. Consider what happens with a PR to jclouds: a committer > effectively approves of those commits once he PUSHES TO OUR' > REPO. Our records tie the push to back to those commits, so > we know where they came from. > > > In the Usergrid workflow, committers carefully review, talk to the > contributor and selectively approve contributions but they do it on GitHub > instead of by command-line access to ASF's Git. In the process you propose, > we still have to trust committers to review and selectively approve commits. > > In either case, we have to trust the committers to review code, check ICLAs, > etc. If we can't trust the committers to do this, everything breaks down. > > I still don't understand your objection. > > - Dave > > > > > > There's nothing like that for usergrid except for the fallacious acceptance > that yes you Dave want to be held personally accountable for everything > everyone else accepts into usergrid's github repo. That is not going to > fly no matter how little you care about being sued over it. > > > > > > On Wednesday, June 18, 2014 12:53 PM, Dave <[email protected]> wrote: > > > On Wed, Jun 18, 2014 at 12:42 PM, Joe Schaefer > <[email protected]> wrote: > > Which is irrelevant as git is DVCS which means commits are local > and their metadata can be forged. Period. End of story. > > Dave, we keep meticulous records of who pushed what to all of our > version control assets because without them provenance cannot be > established definitively. In the case of usergrid we'd need to subpoena > those records from github, assuming they even keep them for any length > of time. This puts us in an untenable situation of compromising foundation > goals simply because committers on a PODLING refuse to be inconvenienced > in any perceptible way. > > Sorry, but no. Usergrid needs to bring their workflow into compliance with > the org's policy on this matter, and it needs to do so right now. > Furthermore > the Incubator probably should require another round of IP clearance for > what's already there given how long usergrid has been in a state of non- > compliance. > > HTH > > > > Sorry to be dense, but I still don't get it. With other ASF projects that > accept PRs a committer manually fetches the PR from GitHub into a local > clone of the ASF Git repo, commits them to that local repo and then pushes > that to the ASF Git. The commits are still happening on GitHub and if you > want to prove where they came from you still have to subpoena GitHub to get > the original commit records and other information. > > Why is this not a problem for other Open Source foundations that are just as > rigid and concerned about IP clearance, for example Eclipse foundation? > > - Dave > > > > > > > > On Wednesday, June 18, 2014 11:49 AM, Dave <[email protected]> wrote: > > > > > > On Wed, Jun 18, 2014 at 11:13 AM, jan i <[email protected]> wrote: > > On 18 June 2014 16:05, Dave <[email protected]> wrote: >> >>> Can you please provide a link to the ASF policy that specifies this rule >>> because the above sentence does not make sense to me. Commits from an >>> incoming GitHub PR *always* occur on GitHub. >>> >>> In our process the commit that merges a PR also happens on GitHub but the >>> commit that merges the PR into ASF Git happens on ASF Git, from a >>> committer. >>> >>> Where is the rule that says a sync process cannot be used? >>> >>if the committer is clearly identified and not hidden by some git common >>user, I cannot see sync as a problem. >> >>BUT if sync happens with one user, and not the original committer we loose >>traceability and that would break our policy. > > > That is not the case, no matter which committer does the commit that merges > the PR into ASF Git, the history of the original PR commits and who did each > is preserved. > > - Dave > > > > > > >
