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 > > > > >
