Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT

On May 26, 2013 2:54 PM, "Jason Trost" <[EMAIL PROTECTED]> 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


> 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
> encumbered licenses, anymore than you would with attached patches/diffs.
>  And if you did by accident, this is always undoable.  PRs allow you to
> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > > I'd be curious if infra has any plans to stand up anything like
> > >
> > > 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
> > > 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
> > not
> > >> necessarily for issues)? IMO, this really amplify's git's usability.
> >