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

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


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" <[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]> 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.
>