Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
Christopher 2013-05-21, 21:44
+
John Vines 2013-05-21, 21:51
+
Corey Nolet 2013-05-21, 22:06
+
David Medinets 2013-05-21, 22:05
+
Christopher 2013-05-21, 22:12
+
Benson Margulies 2013-05-21, 22:25
+
Mike Drob 2013-05-21, 22:25
+
Mattmann, Chris A 2013-05-21, 22:28
+
Benson Margulies 2013-05-21, 22:29
+
Michael Wall 2013-05-21, 23:32
+
Keith Turner 2013-05-22, 14:32
+
Billie Rinaldi 2013-05-22, 14:40
+
Josh Elser 2013-05-22, 14:57
+
David Medinets 2013-05-23, 00:42
+
John Vines 2013-05-23, 00:47
+
Jason Trost 2013-05-23, 12:23
+
Josh Elser 2013-05-23, 13:08
+
Christopher 2013-05-23, 15:40
+
David Medinets 2013-05-23, 18:02
+
Jason Trost 2013-05-26, 18:54
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
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" <[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.
> >
+
David Medinets 2013-05-22, 00:25
+
Josh Elser 2013-05-21, 22:27
+
Christopher 2013-06-01, 20:28
+
Jason Trost 2013-06-02, 17:54
+
Josh Elser 2013-06-04, 13:07
+
Drew Farris 2013-06-05, 02:05
+
Benson Margulies 2013-06-05, 02:24
+
Josh Elser 2013-06-05, 02:16
+
Benson Margulies 2013-06-05, 02:26
+
Sean Busbey 2013-06-05, 02:46
+
Christopher 2013-06-05, 03:35
+
Josh Elser 2013-06-05, 02:49
+
Keith Turner 2013-06-05, 12:44
+
Josh Elser 2013-06-05, 13:16
+
Keith Turner 2013-06-05, 14:51
+
Josh Elser 2013-06-05, 16:23
+
Christopher 2013-06-05, 16:29
+
Billie Rinaldi 2013-06-05, 16:48
+
Christopher 2013-06-05, 17:07
+
Aaron G 2013-06-04, 13:41
+
Josh Elser 2013-06-04, 14:04
+
Aaron G 2013-06-04, 14:09
+
Keith Turner 2013-06-04, 13:35
+
Josh Elser 2013-06-04, 14:01
+
Keith Turner 2013-06-04, 21:51
+
Christopher 2013-06-04, 22:09
+
Christopher 2013-06-04, 22:11
+
David Medinets 2013-06-04, 22:27
+
Billie Rinaldi 2013-06-05, 12:17
+
David Medinets 2013-06-05, 16:49
+
Christopher 2013-06-05, 16:59
+
Christopher 2013-06-04, 18:34
+
Joe Stein 2013-06-04, 18:39
+
Drew Farris 2013-06-05, 01:37
+
Josh Elser 2013-06-04, 20:15
+
Christopher 2013-06-04, 21:05
+
Josh Elser 2013-06-14, 01:41
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB