Sean Busbey 2013-10-15, 19:50
Josh Elser 2013-10-15, 20:03
Billie Rinaldi 2013-10-15, 20:08
Billie Rinaldi 2013-10-15, 20:11
Christopher 2013-10-15, 20:45
Billie Rinaldi 2013-10-15, 22:34
Christopher 2013-10-15, 22:55
Mike Drob 2013-10-15, 22:49
Billie Rinaldi 2013-10-15, 23:29
This quote from that thread seems particularly relevant:
"Again, there is no such requirement [to publish via JIRA] for
commits/pushes at Apache. The person responsible for moving the bits
into our repository is responsible for verifying that they have the
right to do so before the push is made." (I take it that "right to do
so" means that the patch is free of IP).
The fact that pull requests include the SHA1 seem to provide
sufficient documentation of intent... but it probably means we need to
preserve those SHA1s by not rebase-ing pull requests, and only doing a
merge, when we apply them (so that the mapping of the documentation of
intent on the dev list to the actual bits in the repo is preserved).
Additionally, we need to be careful when applying a pull request that
we don't pull in additional commits from the repo that weren't in the
original pull request. That means, we need to follow the instructions
in the pull request carefully. The instructions in the pull request
show how to do a merge from the originating repo's url... which could
have additional commits (or may not even exist anymore)... and not the
pull request url. It's probably safer to apply the patch from the pull
request with 'curl <patchUrl> | git am' or the url to the pull request
(if possible) instead of the originator's repo.
Christopher L Tubbs II
On Tue, Oct 15, 2013 at 6:49 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
> This discussion  from legal-discuss seems to be the most recent word
> regarding github pull requests, and looks like they are fair game.
> : http://markmail.org/thread/3gvsg4qgc2khve27
> On Tue, Oct 15, 2013 at 6:34 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote:
>> On Tue, Oct 15, 2013 at 1:45 PM, Christopher <[EMAIL PROTECTED]> wrote:
>> > It is my understanding that:
>> > The status quo hasn't changed just because we've moved to git.
>> > Committers are still required to perform their due diligence to ensure
>> > that any patch applied has the proper assignment to the ASF. To be
>> > clear, the relevant issue is that patches applied via a pull request
>> > make it easier for committers to overlook that step (because git makes
>> > it so easy!), whereas patches attached to a JIRA are a little more
>> > clear, because by submitting code to JIRA on ASF's infrastructure, one
>> > can assume (unless otherwise stated) that it is owned by the ASF
>> > (although, technically, JIRA doesn't have any Terms of Service stating
>> > this when you sign up for an account... I just checked).
>> The licensing of a "Contribution" is explicitly discussed in the Apache
>> License. So the licensing isn't assumed because it's ASF JIRA, it's
>> assumed because our code is licensed under the Apache License, and any
>> "Contribution" to it is therefore also Apache licensed.
>> Judging by how other projects are handling this, I am left to conclude that
>> a "Contribution" must consist of a patch itself, and not a reference to a
>> patch that exists outside of our infrastructure. I have not yet found
>> explicit guidance about this.
>> > We should have something on our page page that describes a procedure
>> > for explicitly indicating the patch associated with a pull request is
>> > being assigned to the ASF. Perhaps we should just say, "pull requests
>> > are fine, but indicate the assignment explicitly on the ticket
>> > itself".
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>> > On Tue, Oct 15, 2013 at 3:50 PM, Sean Busbey <[EMAIL PROTECTED]>
>> > > I don't recall a discussion happening about granting license to the ASF
>> > > when the repo moved to git. Looking at the git workflow guide, I
>> > > see any mention of licensing.
>> > >
>> > > In other projects (e.g. Avro and Hive) assigning license to the
>> > > is an important part of submitting a contribution. In those projects,
>> > > people are instructed to attach their patches to an open jira so that