On May 26, 2013 2:54 PM, "Jason Trost" <jason.tr...@gmail.com> wrote: > > 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?
It is my understanding that "Under the terms of the AL, any contribution made back to the ASF on ASF infrastructure, such as via a mailing list, JIRA, or Bugzilla, is licensed to the foundation." This might imply that a pull request on GitHub would not have the same property. Billie > 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. > >
