Why would we need the patches in addition to a pull request (PR)? Is it that this artifact is needed for something in particular (an Apache rule) or is this just how things have been managed because SVN in not a peer to peer SCM? When you guys work on projects outside of apache, do you patches for contributions?
After using Githuib (GH) for the past couple years for both work and personal projects, I don't think we would run risks of merging in code with encumbered licenses, anymore than you would with attached patches/diffs. And if you did by accident, this is always undoable. PRs allow you to see the full colored diffs of what is being contributed before merged and they allow you to download the diff patch files if you want. Where I see the most value with moving to GH is drastically lowering the bar to contributions. GH makes it much easier for anyone to fork the project, make some changes/fixes, and submit a pull request. It makes contribution easier and pretty seamless. IMO, this process is easier than having to create an apache JIRA account, produce a patch manually, and attach it to a ticket if you were only contributing to one apache project. I would be curious if there are any other github users who agree/disagree with this? --Jason On May 23, 2013 11:40 AM, "Christopher" <ctubb...@apache.org> wrote: > 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. >
