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 <[email protected]> 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
>
>>
