Re: Hadoop 2.0 Support for Accumulo 1.4 Branch
Just to be clear, we are talking about adding profile support to the pom's for Hadoop 2.2.0 for a 1.4.5 and 1.5.1 release, correct? We are not talking about changing the default build profile for these branches are we? - Original Message - From: Billie Rinaldi billie.rina...@gmail.com To: dev@accumulo.apache.org Sent: Monday, October 14, 2013 11:57:40 PM Subject: Re: Hadoop 2.0 Support for Accumulo 1.4 Branch Thanks for the note, Ted. That vote is for 2.2.0, not -beta. On Oct 14, 2013 7:30 PM, Ted Yu yuzhih...@gmail.com wrote: w.r.t. hadoop-2 release, see this thread: http://search-hadoop.com/m/YSTny19y1Ha1/hadoop+2.2.0 Looks like 2.2.0-beta would pass votes. Cheers On Mon, Oct 14, 2013 at 7:24 PM, Mike Drob md...@mdrob.com wrote: Responses Inline. - Mike On Mon, Oct 14, 2013 at 12:55 PM, Sean Busbey bus...@cloudera.com wrote: Hey All, I'd like to restart the conversation from end July / start August about Hadoop 2 support on the 1.4 branch. Specifically, I'd like to get some requirements ironed out so I can file one or more jiras. I'd also like to get a plan for application. =requirements Here's the requirements I have from the last thread: 1) Maintain existing 1.4 compatibility The only thing I see listed in the pom is Apache release 0.20.203.0. (1.4.4 tag)[1] I don't see anything in the README[2] nor the user manual[3] on other versions being supported. Yep. 2) Gain Hadoop 2 support At the moment, I'm presuming this means Apache release 2.0.4-alpha since that's what 1.5.0 builds against for Hadoop 2. I haven't been following the Hadoop 2 release schedule that closely, but I think the latest is a 2.1.0-beta? Pretty sure it was released after we finished Accumulo 1.5, so there's no reason not to support it in my mind. Depending on an alpha of something strikes me as either unstable or lazy, although I fully understand that it may be neither. 3) Test for correctness on given versions, with = 5 node cluster * Unit Tests * Functional Tests * 24hr continuous + verification * 24hr continuous + verification + agitation * 24hr random walk * 24hr random walk + agitation Keith mentioned running these against a CDH4 cluster, but I presume that since Apache Releases are our stated compatibilities it would actually be against whatever versions we list. Based on #1 and #2 above, I would expect that to be Apache Hadoop 0.20.203.0 and Apache Hadoop 2.0.4-alpha. Hadoop 2 introduces some neat new things like NN HA, which I think it might be worthwhile to test with. At that level it might be more of a verification of the Hadoop code, but I'd like to be comfortable that our DFS Clients switch correctly. This is in addition to the standard release suite that we run. [1] [1]: http://accumulo.apache.org/governance/releasing.html#testing 4) Binary packaging 4a) Either source produces a single binary for all accepted versions or 4b) Instructions for building from source for each versions and somehow flag what (if any) convenience binaries are made for the release. Having run the binary packaging for 1.4.4, I can tell you that it is not in great shape. Christopher cleaned up a lot of the issues in the 1.5 line, so I didn't bother spending a ton of time on them here, but I think RPM and DEB are both broken. It would be nice to be able to specify a Hadoop 2 version for compilation, similar to what happens in the newer code base, which could be back ported, I suppose. 4b seems easier. =application There will be many back-ported patches. Not much active development happens on 1.4.x now, but I presume this should still all go onto a feature branch? Is the community preference that eventually all the changes become a single commit (or one-per-subtask if there are multiple jiras) on the active 1.4 development branch, or that the original patches remain broken out? Not sure what you mean by this. For what it's worth, I'd recommend keeping them broken out. (And that's how the initial development against CDH4 has been done.) [1] http://bit.ly/1fxucMe [2] http://bit.ly/192zUAJ [3] http://accumulo.apache.org/1.4/user_manual/Administration.html#Dependencies -- Sean
Re: Hadoop 2.0 Support for Accumulo 1.4 Branch
On Tue, Oct 15, 2013 at 7:16 AM, dlmar...@comcast.net wrote: Just to be clear, we are talking about adding profile support to the pom's for Hadoop 2.2.0 for a 1.4.5 and 1.5.1 release, correct? We are not talking about changing the default build profile for these branches are we? for 1.4.5-SNAPSHOT I am only talking about adding support Hadoop 2.2.0. I am not suggesting we change the default from building against Hadoop 0.23.203. I'm not sure about the change to 1.5.1-SNAPSHOT. I believe we're talking about changing the hadoop.profile for 2.0 to use the 2.2.0 release. I don't think it makes sense to change the default off of the version in the hadoop.profile for 1.0. Presumably this change would also happen in master. Now that Hadoop 2.x is going to have a GA release, I think it makes sense to have a discussion about changing the default to be the hadoop 2.0 profile for master, but this is not that discussion. -- Sean
Re: Hadoop 2.0 Support for Accumulo 1.4 Branch
On Tue, Oct 15, 2013 at 10:16 AM, Sean Busbey bus...@cloudera.com wrote: On Tue, Oct 15, 2013 at 7:16 AM, dlmar...@comcast.net wrote: Just to be clear, we are talking about adding profile support to the pom's for Hadoop 2.2.0 for a 1.4.5 and 1.5.1 release, correct? We are not talking about changing the default build profile for these branches are we? for 1.4.5-SNAPSHOT I am only talking about adding support Hadoop 2.2.0. I am not suggesting we change the default from building against Hadoop 0.23.203. I mean 0.20.203.0. Ugh, Hadoop versions. -- Sean
Re: Hadoop 2.0 Support for Accumulo 1.4 Branch
I think you meant: Ugh, Hadoop versions.[1] [1] http://blog.cloudera.com/blog/2012/04/apache-hadoop-versions-looking-ahead-3/ On Tue, Oct 15, 2013 at 11:20 AM, Sean Busbey bus...@cloudera.com wrote: On Tue, Oct 15, 2013 at 10:16 AM, Sean Busbey bus...@cloudera.com wrote: On Tue, Oct 15, 2013 at 7:16 AM, dlmar...@comcast.net wrote: Just to be clear, we are talking about adding profile support to the pom's for Hadoop 2.2.0 for a 1.4.5 and 1.5.1 release, correct? We are not talking about changing the default build profile for these branches are we? for 1.4.5-SNAPSHOT I am only talking about adding support Hadoop 2.2.0. I am not suggesting we change the default from building against Hadoop 0.23.203. I mean 0.20.203.0. Ugh, Hadoop versions. -- Sean -- Joey Echeverria Director, Federal FTS Cloudera, Inc.
Functional test broken on 1.4.5-SNAPSHOT and 1.5.1-SNAPSHOT
Could a committer take a look at ACCUMULO-1775[1]? Right now, functional tests fail when run on a clean machine with the 1.4.4 release and the 1.4.x and 1.5.x development branches. The fix is small. -Sean [1]: https://issues.apache.org/jira/browse/ACCUMULO-1775 -- Sean
Re: Functional test broken on 1.4.5-SNAPSHOT and 1.5.1-SNAPSHOT
Yeah, I was planning on applying this shortly. On 10/15/13 12:50 PM, Sean Busbey wrote: Could a committer take a look at ACCUMULO-1775[1]? Right now, functional tests fail when run on a clean machine with the 1.4.4 release and the 1.4.x and 1.5.x development branches. The fix is small. -Sean [1]: https://issues.apache.org/jira/browse/ACCUMULO-1775
Re: Functional test broken on 1.4.5-SNAPSHOT and 1.5.1-SNAPSHOT
On Oct 15, 2013 11:58 AM, Josh Elser josh.el...@gmail.com wrote: Yeah, I was planning on applying this shortly. Sweet, thanks Josh! -- Sean
Re: [VOTE] Accumulo Instamo Archetype 1.4.4-RC3
Uhhh, Mike -- https://repository.apache.org/content/repositories/orgapacheaccumulo-156/archetype-catalog.xml I'm confused as to what you meant now (still working on adding the staging repo locally to test it out properly). On 10/13/13 12:29 AM, Mike Drob wrote: The released tarball has a DEPENDENCIES file that is not in source control. I think we talked about this last time, but wanted to confirm that you were aware of this. All other files match. I don't think this is an issue, since iirc that file is auto-gen'd. Signature on the source release matches the one in the KEYS file. There is no archetype-catalog.xml file deployed, so I have to mvn install before I am able to generate projects using the archetype. After I install however, everything works fine. +1, but I definitely want to see the archetype-catalog.xml taken care of for the next release. Not going to be picky about it on this one because there is an easy workaround. (Maybe it needs to be documented somewhere, though?) On Sat, Oct 12, 2013 at 5:56 PM, Josh Elser josh.el...@gmail.com wrote: Thanks for taking the time to review, Keith. This is scheduled to close tonight. Can any other devs weigh in, please? On 10/11/2013 05:35 PM, Keith Turner wrote: signature and checksum on the soruce tar looks good. Runs fine +1 On Wed, Oct 9, 2013 at 7:20 PM, Josh Elser josh.el...@gmail.com wrote: Round 3, everyone. Changes over RC2: * Manually set tarLongFileMode=gnu for maven-assembly-plugin * Remove maven-source-plugin as Apache parent pom provides this * Remove unnecessary entries from LICENSE and NOTICE * Add LICENSE and NOTICE to the archetype such that the project the archetype generates also has said LICENSE and NOTICE * Rename artifact from 'instamo-archetype' to 'accumulo-instamo-archetype' for clarity Git repo: https://git-wip-us.apache.org/repos/asf/accumulo-instamo-* *** https://git-wip-us.apache.org/**repos/asf/accumulo-instamo-** archetype.githttps://git-wip-**us.apache.org/repos/asf/** accumulo-instamo-archetype.githttps://git-wip-us.apache.org/repos/asf/accumulo-instamo-archetype.git ** Tag: 1.4.4 (f2b2e49ec8ce9a60c298ccdcfc763a6fd05f8da1) Staging repo: https://repository.apache.org/content/repositories/**https://repository.apache.org/**content/repositories/** orgapacheaccumulo-156/https:/**/repository.apache.org/** content/repositories/**orgapacheaccumulo-156/https://repository.apache.org/content/repositories/orgapacheaccumulo-156/ Source release tarball: https://repository.apache.org/https://repository.apache.org/** content/repositories/orgapacheaccumulo-156/org/** apache/accumulo/accumulo-instamo-archetype/1.4.4/** accumulo-instamo-archetype-1.4.4-source-release.tar.gzhtt** ps://repository.apache.org/**content/repositories/** orgapacheaccumulo-156/org/**apache/accumulo/accumulo-** instamo-archetype/1.4.4/**accumulo-instamo-archetype-1.** 4.4-source-release.tar.gzhttps://repository.apache.org/content/repositories/orgapacheaccumulo-156/org/apache/accumulo/accumulo-instamo-archetype/1.4.4/accumulo-instamo-archetype-1.4.4-source-release.tar.gz Pending successful vote after 72hrs, the staging repo will be promoted. I changed how I was doing things before 1.4.4-RCx tags as it would require more manual intervention in the release process. (sidebar: will be writing up this information on the website to make 1.6.0 hopefully easier) - Josh
Re: [VOTE] Accumulo Instamo Archetype 1.4.4-RC3
Ok, I apparently shouldn't have taken Mike's word as gospel :) profile idinstamo-staging/id repositories repository idinstamo/id nameASF staging repo/name urlhttps://repository.apache.org/content/repositories/orgapacheaccumulo-156//url layoutdefault/layout /repository /repositories /profile in my settings.xml, and invoking mvn -Pinstamo-staging archetype:generate -DarchetypeArtifactId=accumulo-instamo-archetype -DarchetypeVersion=1.4.4 -DarchetypeGroupId=org.apache.accumulo Worked for me. Can someone else verify please? I technically never closed the vote (I guess?), so I change my -1 to a +1. I'd still like to get another vote from the community though to make sure it's kosher. On 10/14/13 11:19 AM, Josh Elser wrote: Yah, I agree. If it comes down to having to write something else just to get what we want to begin with (one-command install), we should just do it correctly. Self -1 On 10/14/2013 11:15 AM, Michael Berman wrote: One of the big advantages of an archetype is that it's convenient and consistent to use...I agree that requiring a download and install in order to use the archetype really cuts down on its usefulness. I don't get a vote, but if I did, I think I would need a clean invocation path in order to give my +1. (And I don't think a custom one-off shell script that messes with someone's local repo would qualify) On Mon, Oct 14, 2013 at 7:19 AM, Mike Drob md...@mdrob.com wrote: On Oct 14, 2013 12:14 AM, Josh Elser josh.el...@gmail.com wrote: Well, dang. My intent was definitely to *not* make a user have to download, install and then invoke the archetype, but provide a single maven command to be run to get up and running. Could wrap this up in a shell script? Installing to the local repo/catalog is a pretty nasty side effect though. I hate doing it, but that might be a non-starter (even as the guy repeatedly cutting these releases). I haven't decided my opinion on whether or not this is super important for a 1.4.x version of the code. Thanks for the information either way, Mike. On 10/13/2013 12:29 AM, Mike Drob wrote: There is no archetype-catalog.xml file deployed, so I have to mvn install before I am able to generate projects using the archetype. After I install however, everything works fine.
accumulo pull request: ACCUMULO-1730 improvements
Github user jstoneham closed the pull request at: https://github.com/apache/accumulo/pull/1
accumulo pull request: ACCUMULO-1730 improvements
Github user jstoneham closed the pull request at: https://github.com/apache/accumulo/pull/2
accumulo pull request: ACCUMULO-1730 improvements
GitHub user jstoneham opened a pull request: https://github.com/apache/accumulo/pull/3 ACCUMULO-1730 improvements Correct start and end indices for AND and OR nodes. See https://issues.apache.org/jira/browse/ACCUMULO-1730 for discussion. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jstoneham/accumulo ACCUMULO-1730 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/accumulo/pull/3.patch commit 9ceb320e1742a7b0fbb3bd753d28453e9313f517 Author: John Stoneham jstone...@texeltek.com Date: 2013-10-15T17:14:14Z ACCUMULO-1730 Rename variable for clarity. commit 33118cb721b9598af5cbe26cd4048ecb7189f0a0 Author: John Stoneham jstone...@texeltek.com Date: 2013-10-15T17:15:00Z ACCUMULO-1730 Correct ParseTree start/end markers for logical connector nodes. commit 876c5ce5ee9a039d56c8e4c7ca04d0401a47cdac Author: John Stoneham jstone...@texeltek.com Date: 2013-10-15T17:15:19Z ACCUMULO-1730 Expose ColumnVisibility normalize/stringify methods.
Re: accumulo pull request: ACCUMULO-1730 improvements
Committed and pushed. -Eric On Tue, Oct 15, 2013 at 1:17 PM, jstoneham g...@git.apache.org wrote: GitHub user jstoneham opened a pull request: https://github.com/apache/accumulo/pull/3 ACCUMULO-1730 improvements Correct start and end indices for AND and OR nodes. See https://issues.apache.org/jira/browse/ACCUMULO-1730 for discussion. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jstoneham/accumulo ACCUMULO-1730 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/accumulo/pull/3.patch commit 9ceb320e1742a7b0fbb3bd753d28453e9313f517 Author: John Stoneham jstone...@texeltek.com Date: 2013-10-15T17:14:14Z ACCUMULO-1730 Rename variable for clarity. commit 33118cb721b9598af5cbe26cd4048ecb7189f0a0 Author: John Stoneham jstone...@texeltek.com Date: 2013-10-15T17:15:00Z ACCUMULO-1730 Correct ParseTree start/end markers for logical connector nodes. commit 876c5ce5ee9a039d56c8e4c7ca04d0401a47cdac Author: John Stoneham jstone...@texeltek.com Date: 2013-10-15T17:15:19Z ACCUMULO-1730 Expose ColumnVisibility normalize/stringify methods.
accumulo pull request: ACCUMULO-1730 improvements
Github user jstoneham closed the pull request at: https://github.com/apache/accumulo/pull/3
Contributions from github pull requests and license grant
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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork -- Sean
Re: [VOTE] Accumulo Instamo Archetype 1.4.4-RC3
If you need another vote, you can have my +1 I verified: * good GPG sigs, sha1s, md5s * source tarball and zip match git tag (except generated DEPENDENCIES file, which is okay) * HEAD of tag matches specified commit sha1 * tag builds reproducibly (mvn verify -P apache-release) * can create new project from archetype in staging repo * created project can build (mvn verify) * created project can run MapReduce and shell commands in README * no obvious problems in POM * contents of jar files look fine Encountered issues (not serious, can be improved in future releases or not at all): * not sure tarLongFileMode=gnu worked (file *.tar.gz still reports it as gzip compressed data, from FAT filesystem) * unit test that starts mini should be IT instead -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Oct 15, 2013 at 1:24 PM, Josh Elser josh.el...@gmail.com wrote: Ok, I apparently shouldn't have taken Mike's word as gospel :) profile idinstamo-staging/id repositories repository idinstamo/id nameASF staging repo/name urlhttps://repository.apache.org/content/repositories/orgapacheaccumulo-156//url layoutdefault/layout /repository /repositories /profile in my settings.xml, and invoking mvn -Pinstamo-staging archetype:generate -DarchetypeArtifactId=accumulo-instamo-archetype -DarchetypeVersion=1.4.4 -DarchetypeGroupId=org.apache.accumulo Worked for me. Can someone else verify please? I technically never closed the vote (I guess?), so I change my -1 to a +1. I'd still like to get another vote from the community though to make sure it's kosher. On 10/14/13 11:19 AM, Josh Elser wrote: Yah, I agree. If it comes down to having to write something else just to get what we want to begin with (one-command install), we should just do it correctly. Self -1 On 10/14/2013 11:15 AM, Michael Berman wrote: One of the big advantages of an archetype is that it's convenient and consistent to use...I agree that requiring a download and install in order to use the archetype really cuts down on its usefulness. I don't get a vote, but if I did, I think I would need a clean invocation path in order to give my +1. (And I don't think a custom one-off shell script that messes with someone's local repo would qualify) On Mon, Oct 14, 2013 at 7:19 AM, Mike Drob md...@mdrob.com wrote: On Oct 14, 2013 12:14 AM, Josh Elser josh.el...@gmail.com wrote: Well, dang. My intent was definitely to *not* make a user have to download, install and then invoke the archetype, but provide a single maven command to be run to get up and running. Could wrap this up in a shell script? Installing to the local repo/catalog is a pretty nasty side effect though. I hate doing it, but that might be a non-starter (even as the guy repeatedly cutting these releases). I haven't decided my opinion on whether or not this is super important for a 1.4.x version of the code. Thanks for the information either way, Mike. On 10/13/2013 12:29 AM, Mike Drob wrote: There is no archetype-catalog.xml file deployed, so I have to mvn install before I am able to generate projects using the archetype. After I install however, everything works fine.
Re: Contributions from github pull requests and license grant
We should probably be ensuring that we have something stating that the contributor is assigning license to the ASF. I remember talking about this, but I don't recall the outcome (will have to search history). I'm not sure if there are specific steps that need to be formally followed or if the contributor stating the above on a Jira issue is sufficient. On 10/15/13 3:50 PM, Sean Busbey wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork
Re: Contributions from github pull requests and license grant
Here [1] is another data point. On Tue, Oct 15, 2013 at 1:03 PM, Josh Elser josh.el...@gmail.com wrote: We should probably be ensuring that we have something stating that the contributor is assigning license to the ASF. I remember talking about this, but I don't recall the outcome (will have to search history). I'm not sure if there are specific steps that need to be formally followed or if the contributor stating the above on a Jira issue is sufficient. On 10/15/13 3:50 PM, Sean Busbey wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/**git.htmlhttp://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/**confluence/display/AVRO/How+** To+Contribute#HowToContribute-**Contributingyourworkhttps://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/**confluence/display/Hive/**HowToContribute#** HowToContribute-**Contributingyourworkhttps://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork
Re: Contributions from github pull requests and license grant
Oops, sorry [1]. All of these links still say that you explicitly need to check a box assigning license to the ASF. That is not actually true: any code submitted through ASF infrastructure is assumed to have license assigned to the ASF, and the checkbox used to exist as a way not to assign license. The checkbox no longer exists. Anyway, I haven't seen any guidance yet that says we can accept pull requests without the contents of the patch also being attached to a ticket. [1]: http://karaf.apache.org/manual/latest-2.3.x/developers-guide/github-contributions.html On Tue, Oct 15, 2013 at 1:08 PM, Billie Rinaldi billie.rina...@gmail.comwrote: Here [1] is another data point. On Tue, Oct 15, 2013 at 1:03 PM, Josh Elser josh.el...@gmail.com wrote: We should probably be ensuring that we have something stating that the contributor is assigning license to the ASF. I remember talking about this, but I don't recall the outcome (will have to search history). I'm not sure if there are specific steps that need to be formally followed or if the contributor stating the above on a Jira issue is sufficient. On 10/15/13 3:50 PM, Sean Busbey wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/**git.htmlhttp://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/**confluence/display/AVRO/How+** To+Contribute#HowToContribute-**Contributingyourworkhttps://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/**confluence/display/Hive/**HowToContribute#** HowToContribute-**Contributingyourworkhttps://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork
Re: Contributions from github pull requests and license grant
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). 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 bus...@cloudera.com wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork -- Sean
Re: Contributions from github pull requests and license grant
On Tue, Oct 15, 2013 at 1:45 PM, Christopher ctubb...@apache.org 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 bus...@cloudera.com wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork -- Sean
Re: Contributions from github pull requests and license grant
This discussion [1] from legal-discuss seems to be the most recent word regarding github pull requests, and looks like they are fair game. [1]: http://markmail.org/thread/3gvsg4qgc2khve27 On Tue, Oct 15, 2013 at 6:34 PM, Billie Rinaldi billie.rina...@gmail.comwrote: On Tue, Oct 15, 2013 at 1:45 PM, Christopher ctubb...@apache.org 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 bus...@cloudera.com wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork -- Sean
Re: Contributions from github pull requests and license grant
On Tue, Oct 15, 2013 at 6:34 PM, Billie Rinaldi billie.rina...@gmail.com wrote: 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. I think we (specifically, me) are getting mixed up on the terminology. I didn't think we were talking about what the license is (contributions are most certainly AL 2.0 licensed), so much as its assignment (or perhaps, rather, the assignment of ownership or copyright), which determines things like whether the license can be changed (relicensed under a future AL 3.0, for instance), and how we cite it (eg. do we have to put something separate in the NOTICE file). 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. If that's true, then I'm not sure how it benefits us to have the ASF infrastructure forward pull requests to the GitHub mirror to our dev list. Instead, we should emphasize how to create patches with git format-patch, and how to apply them with a quick curl JIRA patch url | git am or similar command.
Re: Contributions from github pull requests and license grant
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 http://gravatar.com/ctubbsii On Tue, Oct 15, 2013 at 6:49 PM, Mike Drob md...@mdrob.com wrote: This discussion [1] from legal-discuss seems to be the most recent word regarding github pull requests, and looks like they are fair game. [1]: http://markmail.org/thread/3gvsg4qgc2khve27 On Tue, Oct 15, 2013 at 6:34 PM, Billie Rinaldi billie.rina...@gmail.comwrote: On Tue, Oct 15, 2013 at 1:45 PM, Christopher ctubb...@apache.org 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 bus...@cloudera.com wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork -- Sean
Re: Contributions from github pull requests and license grant
Brilliant! Thanks for finding that thread, Mike. On Oct 15, 2013 3:50 PM, Mike Drob md...@mdrob.com wrote: This discussion [1] from legal-discuss seems to be the most recent word regarding github pull requests, and looks like they are fair game. [1]: http://markmail.org/thread/3gvsg4qgc2khve27 On Tue, Oct 15, 2013 at 6:34 PM, Billie Rinaldi billie.rina...@gmail.com wrote: On Tue, Oct 15, 2013 at 1:45 PM, Christopher ctubb...@apache.org 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 bus...@cloudera.com wrote: 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[1], I don't see any mention of licensing. In other projects (e.g. Avro[2] and Hive[3]) assigning license to the ASF is an important part of submitting a contribution. In those projects, people are instructed to attach their patches to an open jira so that license can be granted; pull requests from github generally aren't allowed. Do we have a stance as a project on this? I think those two projects basically say that the grant is required by the Apache License itself. Are there ASF rules that can provide guidance on this? -Sean [1]: http://accumulo.apache.org/git.html [2]: https://cwiki.apache.org/confluence/display/AVRO/How+To+Contribute#HowToContribute-Contributingyourwork [3]: https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-Contributingyourwork -- Sean
Re: linking to the repos for Accumulo contrib projects
New page and also linked from the source page makes the most sense to me. On Oct 15, 2013 1:20 AM, Sean Busbey bus...@cloudera.com wrote: Hiya! I was just looking for the current wikisearch example and had some difficulty. I ended up tracking through the INFRA ticket to switch to git[1] followed by looking at the top level ASF repo list to find the specific repo name[2]. (for those searching in the future who find this message, it's accumulo-wikisearch [3]) Could we add a link to each of the contrib project repos on the main site? I don't know if it'd be better on the Source Guide page, Paper and Other Links, or on a new page off of the menu. If anyone has a preference I'd like to know before I create a doc jira and file a patch. If no one else has a preference, I'd say a new page would be appropriate. -Sean [1]: https://issues.apache.org/jira/browse/INFRA-6392 [2]: https://git-wip-us.apache.org/repos/asf?s=accumulo* [3]: https://git-wip-us.apache.org/repos/asf?p=accumulo-wikisearch.git;a=summary -- Sean
