Thanks for the clarifications, Brett, and for making these comments on a public list where the podling committers can see them.
- Dave On Wed, Jun 18, 2014 at 7:25 PM, Brett Porter <[email protected]> wrote: > 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 > > > >
