Hey Dave Lets discuss on freenode in #usergrid, we can record via ASFbot and send the minutes to the dev list. If this does not work then we can try a hangout
-Jake On Mon, Jun 9, 2014 at 6:06 PM, Dave <[email protected]> wrote: > Jake, would you be willing to join a Google Hangout session with Rod, > Todd, I and anybody else who would like to join so we can work out a plan > for the contribution workflow? Maybe sometime this week? > > The email back-and-forth is not working well. I volunteer to write up the > minutes of the meeting so we can reflect it back to the mailing list. > > - Dave > > > > > On Thu, Jun 5, 2014 at 8:56 AM, Rod Simpson <[email protected]> wrote: > >> We have to find a way to avoid this. It is completely inefficient and >> simply doesn't make sense. Git repos are mirrors of one another - as long >> as a synch occurs, where the commit happens is irrelevant. What matters is >> that we vet the IP and ICLAs and then log everything to the ML. >> >> >> >> >> >> Rod >> >> >> On Wed, Jun 4, 2014 at 10:52 AM, Jake Farrell<[email protected]>, >> wrote: >> >>> Hey Dave >>> Completely agree with having the RTC process, its just where the commit >>> is >>> occurring. You can still submit all PR's against >>> github.com/apache/incubator-usergrid and review and reject as >>> necessary, >>> the only difference is that there is no merge button available as its a >>> read only mirror you are reviewing against. This would be no different >>> than >>> if you where using the Apache Reviewboard instance for project reviews. >>> You >>> would still review and comment on the code and when satisfied close the >>> review and submit the code back to git-wip. >>> >>> -Jake >>> >>> >>> >>> On Wed, Jun 4, 2014 at 12:40 PM, Dave <[email protected]> wrote: >>> >>> > 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 >>> > >>> > >>> >> >
