See INFRA-4104 where the following automated Jira integration was suggested for incoming pull requests:

* Create a new JIRA issue (or use an existing issue referenced in the pull request)
* Link or copy the content of the GitHub pull request issue
* Provide instructions on the GitHub pull request, and provide a link to the JIRA issue
* Close the GitHub pull request

As long as we don't want to start leveraging Github directly for collaboration I think the above process can best take care of directing incoming work to the correct channels.

If someone wants to work on this: we already have a way to trigger a script when a new pull request is made, so all we need is the script that does the above. And as mentioned on INFRA-4104, it would also be a good idea to clarify with legal-discuss@ whether and how pull requests on Github satisfy our legal audit requirements.

Jukka Zitting
added a comment - 24/Nov/11 23:09 See INFRA-4104 where the following automated Jira integration was suggested for incoming pull requests:
* Create a new JIRA issue (or use an existing issue referenced in the pull request)
* Link or copy the content of the GitHub pull request issue
* Provide instructions on the GitHub pull request, and provide a link to the JIRA issue
* Close the GitHub pull request
As long as we don't want to start leveraging Github directly for collaboration I think the above process can best take care of directing incoming work to the correct channels.
If someone wants to work on this: we already have a way to trigger a script when a new pull request is made, so all we need is the script that does the above. And as mentioned on INFRA-4104 , it would also be a good idea to clarify with legal-discuss@ whether and how pull requests on Github satisfy our legal audit requirements.

That seems very weird from a user point of view. Offer patch in GitHub and then feel like they're being told that it should be in JIRA.

Currently it seems to fit our methods in that a pull request = an email to the mailing list with a patch. Ideally replies to that email would go back to GitHub (maybe they do, I'll test), and then we would be able to close the pull request later on.

Is it possible to give me permissions to close the GitHub pull request?

Henri Yandell
added a comment - 24/Nov/11 23:41
That seems very weird from a user point of view. Offer patch in GitHub and then feel like they're being told that it should be in JIRA.
Currently it seems to fit our methods in that a pull request = an email to the mailing list with a patch. Ideally replies to that email would go back to GitHub (maybe they do, I'll test), and then we would be able to close the pull request later on.
Is it possible to give me permissions to close the GitHub pull request?

Henri Yandell
added a comment - 24/Nov/11 23:44 Noting that replies go back to GitHub, though under the user 'apache', whoever that is.
Apologies for not seeing INFRA-4104 ; I looked at the list in the Git component and didn't see anything relevant [ie: I must be blind because 4104 looks blindingly obvious].

I sent email to Github asking about the impact of turning the github.com/apache account into an organization. An organization instead of a single account would make it easier to give people access to stuff like this (and would make more sense also for general administration of the github.com/apache space).

However, if we go down that path, it would probably be better to have a separate Github organization for each PMC that wants to use GH like this (essentially as an alternative to Jira/Bugzilla). I suggest bringing this up on infra-dev@ for a wider discussion of how and why this should be done.

Jukka Zitting
added a comment - 25/Nov/11 11:54 I sent email to Github asking about the impact of turning the github.com/apache account into an organization. An organization instead of a single account would make it easier to give people access to stuff like this (and would make more sense also for general administration of the github.com/apache space).
However, if we go down that path, it would probably be better to have a separate Github organization for each PMC that wants to use GH like this (essentially as an alternative to Jira/Bugzilla). I suggest bringing this up on infra-dev@ for a wider discussion of how and why this should be done.

It looks like we can't easily give people direct access to manage pull requests under github.com/apache, as doing so would open the door for pushing changes directly to those repositories.

In addition to the above Jira-based solution, here's a few ideas on how we could proceed here:

* Add some web form on git(-wip-us).apache.org that allows Apache committers to close pull requests under github.com/apache.
* Support some specific commit message syntax that triggers automatic closing of referenced pull requests.
* Automatically close a pull request right after a notification about it has been sent to the relevant dev@ list.

Jukka Zitting
added a comment - 04/Apr/12 00:26 It looks like we can't easily give people direct access to manage pull requests under github.com/apache, as doing so would open the door for pushing changes directly to those repositories.
In addition to the above Jira-based solution, here's a few ideas on how we could proceed here:
* Add some web form on git(-wip-us).apache.org that allows Apache committers to close pull requests under github.com/apache.
* Support some specific commit message syntax that triggers automatic closing of referenced pull requests.
* Automatically close a pull request right after a notification about it has been sent to the relevant dev@ list.

Jonathan Ellis
added a comment - 03/May/12 17:04 I like the idea to automatically close a pull request right after a notification about it has been sent to the relevant dev@ list. Simple and effective.

Filip Maj
added a comment - 30/May/12 19:13 I like the idea of perhaps simultaneously supporting the below two suggestions.
* Support some specific commit message syntax that triggers automatic closing of referenced pull requests.
Perhaps something like detecting if "closes GH#<pull request ID>" is in the commit message, i.e. "closes/fixes/fix for/etc GH#3" would close github.com/apache/project/pull/2.
* Automatically close a pull request right after a notification about it has been sent to the relevant dev@ list.
We already get an email notification when a pull request comes in, so some reply to this email could work very well too!

I dislike magic messages, because I can never find the syntax for them. Where would we document these magic messages? And I think I'd want the magic message to include "pull" in the message, not just a "GH" moniker and #. And it seems weird that the pull request would be on a commit. How do you close a pull request that doesn't have a commit associated with it?

Generally not a fan of closing pull requests as soon as it's been posted to the dev list, since that's rude as all get out. Unless, perhaps we post a comment in the pull request indicating what has happened (an email has been posted to the dev list) along with some additional advice (you should probably open a JIRA ticket for this, if you haven't already), along with links to various things.

Patrick Mueller
added a comment - 30/May/12 19:33 I dislike magic messages, because I can never find the syntax for them. Where would we document these magic messages? And I think I'd want the magic message to include "pull" in the message, not just a "GH" moniker and #. And it seems weird that the pull request would be on a commit. How do you close a pull request that doesn't have a commit associated with it?
Generally not a fan of closing pull requests as soon as it's been posted to the dev list, since that's rude as all get out. Unless, perhaps we post a comment in the pull request indicating what has happened (an email has been posted to the dev list) along with some additional advice (you should probably open a JIRA ticket for this, if you haven't already), along with links to various things.
Form seems survivable if neither magic message nor auto-close-when-emailed are implemented.
Guess I vote for "auto-close with commen after notification".

Michael Brooks
added a comment - 30/May/12 19:42 I think we should approach the problem from the Github mirroring viewpoint. It would be less confusing the user and be more integrated with the Apache workflow.
- A Github pull request creates an open JIRA issue.
- Comments on the Github pull request mirror as comments on the JIRA issue.
- Comments on the JIRA issue mirror as comments on the Github pull request.
- [Closing | Reopening] the Github pull request [closes | reopens] the JIRA issue.
- [Closing | Reopening] the JIRA issue [closes | reopens] the Github pull request.
Assuming the Github API supports everything needed.
Michael