I'm not exactly sure how pull requests would work. I'd be most comfortable incorporating pull requests where the changes being pulled have also already been submitted as a patch to a ticket, so the pull request is just a separate, more convenient method of merging what has already been donated to the project, and not a replacement for more official mechanisms of contributing code.
I doubt there are 'no-no's, but I suspect there are lots of cautionary messages about inadvertently pulling in code encumbered with restrictive licenses (imagine pulling some merges where an ancestor has encumbered code, but the HEAD doesn't, and we do the pull, then roll revert to a previous commit from that pull, and now have encumbered code that we need to deal with). So, handling merge requests would probably involve a policy like: 1) only merge single, squashed commits from external git repos (this prevents merging potentially restrictive history) 2) require the patch represented by the merge to be first donated to JIRA/ (we do this now) 3) check for any applicable license restrictions/issues. (we do this anyway) -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, May 23, 2013 at 9:08 AM, Josh Elser <josh.el...@gmail.com> wrote: > I'd be curious if infra has any plans to stand up anything like Gerrit. > > We could possibly use Github as a way to handle external requests, but we'd > be missing the nice-ness of automatic merging, etc. I'm not sure if there > any no-no's from the ASF about doing such. > > > On 5/23/13 8:23 AM, Jason Trost wrote: >> >> Would you all be open to using github as well (i.e. for pull requests, not >> necessarily for issues)? IMO, this really amplify's git's usability.
