Thanks for the response. Comments in-line below.
On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <[email protected]> wrote: > You had the flow correct up till > "Committer closes PR and does not merge (because the repo is > read-only)" > > Since the committer is working of git-wip and it is the canonical source > then when they commit the contribution and push it to git-wip there is no > need to merge anywhere else as it will be mirrored to git.a.o and github > will pick this change up and automatically close the pull request and > comment on it for you. The main sticking point is the use of > github.com/usergrid which is where the commit is actually occurring > currently and it needs to occur on git-wip. Switching to using > github.com/apache/incubator-usergrid for PR reviews/discussions will take > care most of the concerns brought up (permissions, commit origin, mailing > list notification). > > The accepted flow being used by most projects right now is as follows: > > - Contributor clones project from > - github.com/apache/incubator-usergrid > - Committer clones project from > - git-wip-us.apache.org/repos/asf/incubator-usergrid.git > I believe that step is a problem. The Usergrid process that we voted in uses GitHub as a code review system, every change made against the master branch must be submitted as a PR in GitHub. That is where we examine the code line-by-line, make comments on specific lines of code, etc. Our process is Review Then Commit (RTC) for the master branch. > - Contributor submits PR to project on > github.com/apache/incubator-usergrid > - Comments automatically echoed to project mailing list > - Committer merges PR into a local clone of the ASF repo > - I've scripted this process out for Mesos, happy to do the same here > if needed > - Committer pushes change to ASF git repo at git-wip-us.apache.org > - Comments or commit hash from the commit to git-wip close out the PR when > github picks up the mirror from git.apache.org > > I'd like to see us switch to this workflow and then outline and work to > improve the process for all projects where any limitations are seen. > (I think our descriptions of the process are a little muddy because we are mixing what a committer does vs. what a contributor who is not a committer does.) How would you adjust your suggested process to ensure all changes against master are done via GitHub PR? Thanks, - Dave
