Hi Dave, On 19 Jun 2014, at 6:07 am, Dave <[email protected]> wrote:
> I read that email from Brett on the board's private mailing list too, but I > did not see any "orders" issued to Usergrid and there was no specific > indication of what things are doing wrong in the Usergrid process. I support what David Nalley wrote, and his summary of my mail. I'm not sure where the disconnect is between you and I. Let me try and respond here, including some of the content from the other mail for others since the link is from a private archive, and see if the context helps get us to the same conclusion. > > Please understand that it is very difficult for us to come up and document a > contributor workflow that conforms with policy when that policy, as far as I > can tell, does not exist. There's no written down policy, because for many years it was implicit - there was one CVS and then SVN repository, and that's what everyone used. Now, there is a Git repository, still labelled experimental, but with some documented constraints (and much discussion over the options in infra-dev and elsewhere). It's reasonable that we document a policy for how commits may arrive there as part of removing the experimental label. It is already documented that releases must be cut from the official repository. The Usergrid proposal said this: "We prefer to use Git as our source control system: git://git.apache.org/usergrid/. If possible, we would like to keep leveraging the extremely useful github facilities for workflow using a process much like that employed by the Apache Cordova project (documented here http://wiki.apache.org/cordova/ContributorWorkflow)." Skimming that link, it appears to be similar to what I've seen described for jclouds and others, not Usergrid. > Can you suggest a project that has an acceptable GitHub / ASF Git process, > one that we should emulate? jClouds has been recommended a couple of times. It sounds like that's what you've tried to model, but misunderstood some of their processes. Andrew Bayer's earlier email was helpful. > > Also, if you could state specifically what things are not acceptable about > the current process from the point of view of both infrastructure and legal, > that would help too. Jake enumerated them at the start of the thread. You've started addressing some of them. The main concern remains the sync process. In my other mail I said: Particular concerns are the process for pushing back to the ASF repo, that it's only at release and not for everything on master, not using Apache authentication for [pushes], and how effectively [Usergrid] are tracking CLAs and apache IDs in what seems like a manual process. I'm unclear how often the push back happens based on the wiki page, your response to my earlier mail, and perusing the commits list. It is problematic that everything gets pushed under the snoopdave account, and it appears to be done in very large chunks. Given the current implementation of the Git service, I'd suggest that you need to: - push to the ASF repo at the same frequency as you would push to GitHub - execute that push authenticated as a the committer doing the push The easiest starting point is to use the ASF Git repo, with the GitHub tooling, as other projects are. From there, as David offered, you can engage with infra to improve the tooling. I am sure that solutions can be worked out with things like the pull request merge buttons. Does looking more closely at the jclouds workflow help? Thanks, Brett
