You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by Dave <sn...@gmail.com> on 2014/06/03 21:50:18 UTC
Usergrid Github workflow
Following up on this thread...
There was some discussion of this topic on the private ASF board of
directors mailing list, but I still don't understand what specific things
about our process do not comply with ASF policy (and I strongly dislike
discussing things like this in private; this is an open source projects and
our discussions should be open).
Anyhow, based on those private discussions, I now understand that the other
projects with GitHub-centric processes do things slightly different than
the way we do things on Usergrid. Processing an incoming PR requires more
manual steps, but they are able to take advantage of some nice Infra
support for echoing GitHub comments back to the project mailing lists and
JIRA integration too. Let's look at what they do.
I believe this is an accurate high-level summary of the ASF approved
process used by other projects:
- Contributor forks projects read only GitHub repo
- Contributor submits PR to project on GitHub
- Comments echoed to project mailing list
- Committer merges PR into a local clone of the ASF repo
- Committer pushes change to ASF git repo
- Committer closes PR and does not merge (because the repo is read-only)
Downsides
- Much less convenient
- Accepting a PR takes many keystrokes instead of one button press
- If you want to work via GitHub you must fork, not commits allowed to
project repo
I believe we need to propose some specific changes to our contribution
workflow, and the seek feedback on the public incubator general and
infrastructure mailing lists. So let's look at our process as it stands
today.
Here is a high level summary of our current process:
- If contributor is committer, they can work in branch of our Github repo
- If not, contributor must work in fork of repo
- Contributor submits PR to project on GitHub
- A committer reviews, comments on and merges the pull request
- Periodically a committer pulls from GitHub repo and pushes ASF Git repo
Downsides
- PRs and comments not echoed to project mailing list (yet)
- Manual steps required to sync GitHub repo with ASF Git repo (but this
could be automated).
So, apart from fixing those "downsides" what do we need to fix about our
process? In other projects the contributor's commit happens on GitHub, it
is merged and pushed to ASF Git. That is essentially the same thing we do.
Like I said, I still don't understand what specific problems there are with
our process, except from those downsides.
So, I see at least two possible options for us:
1) adopt the Infra-approved process and and accept the downsides, extra
manual steps, required committer forks etc.
2) fix this limitations of our process, i.e. figure out how to echo PRs and
PR commands to our mailing lists and automate our sync process.
Thoughts?
Thanks,
- Dave
>
Re: Usergrid Github workflow
Posted by Rod Simpson <ro...@rodsimpson.com>.
We can fix the problem of comments not getting echoed to the ML very easily. Just need to set up something to catch the post-recieve hook can post the message to the ML. I can code this up in PHP in just a few hours. We just need somewhere to park the job.
--
Rod Simpson
@rockerston
rodsimpson.com
On June 3, 2014 at 12:50:47 PM, Dave (snoopdave@gmail.com) wrote:
Following up on this thread...
There was some discussion of this topic on the private ASF board of
directors mailing list, but I still don't understand what specific things
about our process do not comply with ASF policy (and I strongly dislike
discussing things like this in private; this is an open source projects and
our discussions should be open).
Anyhow, based on those private discussions, I now understand that the other
projects with GitHub-centric processes do things slightly different than
the way we do things on Usergrid. Processing an incoming PR requires more
manual steps, but they are able to take advantage of some nice Infra
support for echoing GitHub comments back to the project mailing lists and
JIRA integration too. Let's look at what they do.
I believe this is an accurate high-level summary of the ASF approved
process used by other projects:
- Contributor forks projects read only GitHub repo
- Contributor submits PR to project on GitHub
- Comments echoed to project mailing list
- Committer merges PR into a local clone of the ASF repo
- Committer pushes change to ASF git repo
- Committer closes PR and does not merge (because the repo is read-only)
Downsides
- Much less convenient
- Accepting a PR takes many keystrokes instead of one button press
- If you want to work via GitHub you must fork, not commits allowed to
project repo
I believe we need to propose some specific changes to our contribution
workflow, and the seek feedback on the public incubator general and
infrastructure mailing lists. So let's look at our process as it stands
today.
Here is a high level summary of our current process:
- If contributor is committer, they can work in branch of our Github repo
- If not, contributor must work in fork of repo
- Contributor submits PR to project on GitHub
- A committer reviews, comments on and merges the pull request
- Periodically a committer pulls from GitHub repo and pushes ASF Git repo
Downsides
- PRs and comments not echoed to project mailing list (yet)
- Manual steps required to sync GitHub repo with ASF Git repo (but this
could be automated).
So, apart from fixing those "downsides" what do we need to fix about our
process? In other projects the contributor's commit happens on GitHub, it
is merged and pushed to ASF Git. That is essentially the same thing we do.
Like I said, I still don't understand what specific problems there are with
our process, except from those downsides.
So, I see at least two possible options for us:
1) adopt the Infra-approved process and and accept the downsides, extra
manual steps, required committer forks etc.
2) fix this limitations of our process, i.e. figure out how to echo PRs and
PR commands to our mailing lists and automate our sync process.
Thoughts?
Thanks,
- Dave
>
Re: Usergrid Github workflow
Posted by Dave <sn...@gmail.com>.
Sorry about the delayed response. Yes, let's try meeting in the #usergrid
IRC channel on Freenet. I think we need at least Jake, Rod and myself for
this discussion but anybody who is interested is welcome and encouraged to
join.
I can make any of these times on Monday, Tuesday or Wednesday of next week:
11am US Eastern Time (GMT - 5)
1pm US Eastern Time (GMT - 5)
4pm US Eastern Time (GMT - 5)
What time/day would be good for you folks?
Thanks,
Dave
On Tue, Jun 10, 2014 at 11:15 AM, Jake Farrell <jf...@apache.org> wrote:
> 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 <sn...@gmail.com> 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 <ro...@rodsimpson.com> 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<jf...@apache.org>,
>>> 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 <sn...@gmail.com> wrote:
>>>>
>>>> > Thanks for the response. Comments in-line below.
>>>> >
>>>> >
>>>> > On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <jf...@apache.org>
>>>> 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
>>>> >
>>>> >
>>>>
>>>
>>
>
Re: Usergrid Github workflow
Posted by Jake Farrell <jf...@apache.org>.
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 <sn...@gmail.com> 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 <ro...@rodsimpson.com> 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<jf...@apache.org>,
>> 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 <sn...@gmail.com> wrote:
>>>
>>> > Thanks for the response. Comments in-line below.
>>> >
>>> >
>>> > On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <jf...@apache.org>
>>> 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
>>> >
>>> >
>>>
>>
>
Re: Usergrid Github workflow
Posted by Dave <sn...@gmail.com>.
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 <ro...@rodsimpson.com> 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<jf...@apache.org>, 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 <sn...@gmail.com> wrote:
>>
>> > Thanks for the response. Comments in-line below.
>> >
>> >
>> > On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <jf...@apache.org>
>> 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
>> >
>> >
>>
>
Re: Usergrid Github workflow
Posted by Rod Simpson <ro...@rodsimpson.com>.
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<jf...@apache.org>, 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 <sn...@gmail.com> wrote:
> Thanks for the response. Comments in-line below.
>
>
> On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <jf...@apache.org> 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
>
>
Re: Usergrid Github workflow
Posted by Jake Farrell <jf...@apache.org>.
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 <sn...@gmail.com> wrote:
> Thanks for the response. Comments in-line below.
>
>
> On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <jf...@apache.org> 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
>
>
Re: Usergrid Github workflow
Posted by Dave <sn...@gmail.com>.
Thanks for the response. Comments in-line below.
On Wed, Jun 4, 2014 at 7:23 AM, Jake Farrell <jf...@apache.org> 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
Re: Usergrid Github workflow
Posted by Jake Farrell <jf...@apache.org>.
Hey Dave
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
- 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.
-Jake
On Tue, Jun 3, 2014 at 3:50 PM, Dave <sn...@gmail.com> wrote:
> Following up on this thread...
>
> There was some discussion of this topic on the private ASF board of
> directors mailing list, but I still don't understand what specific things
> about our process do not comply with ASF policy (and I strongly dislike
> discussing things like this in private; this is an open source projects and
> our discussions should be open).
>
> Anyhow, based on those private discussions, I now understand that the
> other projects with GitHub-centric processes do things slightly different
> than the way we do things on Usergrid. Processing an incoming PR requires
> more manual steps, but they are able to take advantage of some nice Infra
> support for echoing GitHub comments back to the project mailing lists and
> JIRA integration too. Let's look at what they do.
>
> I believe this is an accurate high-level summary of the ASF approved
> process used by other projects:
> - Contributor forks projects read only GitHub repo
> - Contributor submits PR to project on GitHub
> - Comments echoed to project mailing list
> - Committer merges PR into a local clone of the ASF repo
> - Committer pushes change to ASF git repo
> - Committer closes PR and does not merge (because the repo is read-only)
>
> Downsides
> - Much less convenient
> - Accepting a PR takes many keystrokes instead of one button press
> - If you want to work via GitHub you must fork, not commits allowed to
> project repo
>
> I believe we need to propose some specific changes to our contribution
> workflow, and the seek feedback on the public incubator general and
> infrastructure mailing lists. So let's look at our process as it stands
> today.
>
> Here is a high level summary of our current process:
> - If contributor is committer, they can work in branch of our Github repo
> - If not, contributor must work in fork of repo
> - Contributor submits PR to project on GitHub
> - A committer reviews, comments on and merges the pull request
> - Periodically a committer pulls from GitHub repo and pushes ASF Git repo
>
> Downsides
> - PRs and comments not echoed to project mailing list (yet)
> - Manual steps required to sync GitHub repo with ASF Git repo (but this
> could be automated).
>
> So, apart from fixing those "downsides" what do we need to fix about our
> process? In other projects the contributor's commit happens on GitHub, it
> is merged and pushed to ASF Git. That is essentially the same thing we do.
> Like I said, I still don't understand what specific problems there are with
> our process, except from those downsides.
>
> So, I see at least two possible options for us:
>
> 1) adopt the Infra-approved process and and accept the downsides, extra
> manual steps, required committer forks etc.
>
> 2) fix this limitations of our process, i.e. figure out how to echo PRs
> and PR commands to our mailing lists and automate our sync process.
>
>
> Thoughts?
>
> Thanks,
> - Dave
>
>>
Fwd: Usergrid Github workflow
Posted by Martin Harris <ma...@cloudsoftcorp.com>.
Hi Folks,
Given the recent discussions here, I thought this might be of interest to
those of you not also subscribed to the usergrid dev list
Cheers
M
---------- Forwarded message ----------
From: Dave <sn...@gmail.com>
Date: 3 June 2014 20:50
Subject: Usergrid Github workflow
To: "jfarrell@apache.org" <jf...@apache.org>
Cc: "dev@usergrid.incubator.apache.org" <de...@usergrid.incubator.apache.org>
Following up on this thread...
There was some discussion of this topic on the private ASF board of
directors mailing list, but I still don't understand what specific things
about our process do not comply with ASF policy (and I strongly dislike
discussing things like this in private; this is an open source projects and
our discussions should be open).
Anyhow, based on those private discussions, I now understand that the other
projects with GitHub-centric processes do things slightly different than
the way we do things on Usergrid. Processing an incoming PR requires more
manual steps, but they are able to take advantage of some nice Infra
support for echoing GitHub comments back to the project mailing lists and
JIRA integration too. Let's look at what they do.
I believe this is an accurate high-level summary of the ASF approved
process used by other projects:
- Contributor forks projects read only GitHub repo
- Contributor submits PR to project on GitHub
- Comments echoed to project mailing list
- Committer merges PR into a local clone of the ASF repo
- Committer pushes change to ASF git repo
- Committer closes PR and does not merge (because the repo is read-only)
Downsides
- Much less convenient
- Accepting a PR takes many keystrokes instead of one button press
- If you want to work via GitHub you must fork, not commits allowed to
project repo
I believe we need to propose some specific changes to our contribution
workflow, and the seek feedback on the public incubator general and
infrastructure mailing lists. So let's look at our process as it stands
today.
Here is a high level summary of our current process:
- If contributor is committer, they can work in branch of our Github repo
- If not, contributor must work in fork of repo
- Contributor submits PR to project on GitHub
- A committer reviews, comments on and merges the pull request
- Periodically a committer pulls from GitHub repo and pushes ASF Git repo
Downsides
- PRs and comments not echoed to project mailing list (yet)
- Manual steps required to sync GitHub repo with ASF Git repo (but this
could be automated).
So, apart from fixing those "downsides" what do we need to fix about our
process? In other projects the contributor's commit happens on GitHub, it
is merged and pushed to ASF Git. That is essentially the same thing we do.
Like I said, I still don't understand what specific problems there are with
our process, except from those downsides.
So, I see at least two possible options for us:
1) adopt the Infra-approved process and and accept the downsides, extra
manual steps, required committer forks etc.
2) fix this limitations of our process, i.e. figure out how to echo PRs and
PR commands to our mailing lists and automate our sync process.
Thoughts?
Thanks,
- Dave
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855