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

Reply via email to