Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: On Jun 19, 2012, at 8:13 AM, Kevan Miller wrote: On Jun 18, 2012, at 9:51 PM, Jun Rao wrote: Kevin, Thanks for the comments. Just want to clarify on your points on LICENSE/NOTICE. Our LICENSE/NOTICE covers all jars included in the source, not those pulled in during building. We had a long discussion during our 1st release and in the end, we have reached the conclusion that we don't have to document LICENSE/NOTICE for jars not included in the source (since we are just doing a source release). Please correct me if you think this is blocking the release. We have to include a small number of jars in the source because there is no easy way to pull them in automatically. Hi Jun, Well, IMO, a source-only release does not free you from your responsibilities of creating/reviewing the licensing of what your build produces. Would it be ok if your source-only release builds binaries with artifacts that are not open source or an approved open source license? How am I expected to review your release if you can't/haven't documented your LICENSE/NOTICE files? Your users will expect to build Kafka (not simply use Kafka source). IMO, you have a responsibility/requirement to document the licensing of Kafka, not just the portions of Kafka (i.e. Kafka source code) that you choose to document. There's precedent for not doing this, e.g. the previous release of Kafka and I am certain other ASF releases. Precedence has great weight. Licensing issues were raised with the last release of Kafka. A source-only release was created to avoid the issue -- a practice which is debatable, at very best, and I is IMO wrong. From an ASF perspective, all releases are source releases. In some instances, projects also create/distribute binary artifacts. So now, a new release is being created. Yet, no progress has been made to address the same licensing issues. I see your note in the current vote thread. That seems to be a good plan. I think we differ on what is required/optional and when that work should occur. With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... FWIW, what I did last time was hand review every single jar and make sure that it's AL 2.0 compatible; yes someone owes me a beer. I wish there was a rat target for sbt. Yep. This is something the PPMC should/must be doing. And we should be able to verify by comparing binary artifacts against LICENSE/NOTICE files. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] [PROPOSAL] Allura to enter the Incubator
Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 binding Regards, Alan On Jun 21, 2012, at 9:34 AM, Rich Bowen wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Jun 21, 2012, at 6:15 AM, Kevan Miller wrote: On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: On Jun 19, 2012, at 8:13 AM, Kevan Miller wrote: On Jun 18, 2012, at 9:51 PM, Jun Rao wrote: Kevin, Thanks for the comments. Just want to clarify on your points on LICENSE/NOTICE. Our LICENSE/NOTICE covers all jars included in the source, not those pulled in during building. We had a long discussion during our 1st release and in the end, we have reached the conclusion that we don't have to document LICENSE/NOTICE for jars not included in the source (since we are just doing a source release). Please correct me if you think this is blocking the release. We have to include a small number of jars in the source because there is no easy way to pull them in automatically. Hi Jun, Well, IMO, a source-only release does not free you from your responsibilities of creating/reviewing the licensing of what your build produces. Would it be ok if your source-only release builds binaries with artifacts that are not open source or an approved open source license? How am I expected to review your release if you can't/haven't documented your LICENSE/NOTICE files? Your users will expect to build Kafka (not simply use Kafka source). IMO, you have a responsibility/requirement to document the licensing of Kafka, not just the portions of Kafka (i.e. Kafka source code) that you choose to document. There's precedent for not doing this, e.g. the previous release of Kafka and I am certain other ASF releases. Precedence has great weight. Licensing issues were raised with the last release of Kafka. A source-only release was created to avoid the issue -- a practice which is debatable, at very best, and I is IMO wrong. From an ASF perspective, all releases are source releases. In some instances, projects also create/distribute binary artifacts. So now, a new release is being created. Yet, no progress has been made to address the same licensing issues. I see your note in the current vote thread. That seems to be a good plan. I think we differ on what is required/optional and when that work should occur. As I mentioned before, we didn't organize the LICENSE/NOTICE files in this manner before and I'm certain that other projects have not done it as well. The fact that it's a source release doesn't seem relevant to me. I could be missing something. With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... I checked, there don't seem to be any. FWIW, what I did last time was hand review every single jar and make sure that it's AL 2.0 compatible; yes someone owes me a beer. I wish there was a rat target for sbt. Yep. This is something the PPMC should/must be doing. And we should be able to verify by comparing binary artifacts against LICENSE/NOTICE files. Reviewing dependencies, yes. How LICENSE/NOTICE files are populated with regards to dependencies is your opinion; an opinion that I do share but don't feel it needs to hold up a release as long as the dependencies are reviewed. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
On Thu, Jun 21, 2012 at 12:34 PM, Rich Bowen rbo...@rcbowen.com wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) +1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Thu, Jun 21, 2012 at 6:15 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... I feel like I'm missing something. There shouldn't be any difference between a first-order dependency and a transitive dependency. All that matters is whether or not the dependency is bundled, right?[1] Why would we need ASF rules regarding *transitive* dependency license documentation in particular? So long as we bundle the bits, we have to bundle the licensing -- possibly bubbling up any relevant ALv2 NOTICE provisions into the top-level NOTICE since that's what the ALv2 requires. On the other hand, if the bits aren't bundled, then the licensing shouldn't be bundled either. If the bundled dependencies of the canonical ASF source release and a convenience binary differ, then their licensing must be analyzed separately and may differ. If a project has a gazillion dependencies, regardless of whether those dependencies are direct or transitive, that makes dealing with licensing more challenging, but it doesn't change our legal obligations. Marvin Humphrey [1] Leaving aside concerns about copyleft, field of use restrictions, etc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (binding) From a mobile device - forgive errors and terseness On Jun 21, 2012 5:35 PM, Rich Bowen rbo...@rcbowen.com wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
Did these dependencies change between 0.7.0 and 0.7.1? -C On Wed, Jun 20, 2012 at 10:36 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jun 20, 2012, at 9:19 AM, Joe Stein wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). I need help checking these jars. What I recommend is that we update NOTICE in trunk as we attribute licenses to the jars below. This way we still vet the jars, update the NOTICE/LICENSE file in trunk for the next release, and not force Joe to cut a new release to include the updated NOTICE/LICENSE file. This will make subsequent releases go much easier. BTW, the keys and signatures are fine. Tests pass. (linkedin)[acabrera-mn:kafka-0.7.1-incubating 525]$ find . -name *.jar ./contrib/hadoop-consumer/lib/piggybank.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-el-1.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-net-1.4.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/core-3.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hadoop-core-0.20.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hsqldb-1.8.0.10.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-compiler-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-runtime-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jets3t-0.7.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-api-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/kfs-0.3.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/pig-0.8.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/xmlenc-0.52.jar ./contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.1.jar ./contrib/hadoop-producer/lib/piggybank.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.0.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-el-1.0.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (non-binding) On Thu, Jun 21, 2012 at 11:20 AM, Ross Gardler rgard...@opendirective.com wrote: +1 (binding) From a mobile device - forgive errors and terseness On Jun 21, 2012 5:35 PM, Rich Bowen rbo...@rcbowen.com wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (non-binding) On Thursday, June 21, 2012 at 12:34 PM, Rich Bowen wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com (mailto:rbo...@rcbowen.com) :: @rbowen rbo...@apache.org (mailto:rbo...@apache.org) -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
On Jun 21, 2012, at 12:34 PM, Rich Bowen wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) +1 (non-binding) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 --tim On Thu, Jun 21, 2012 at 12:34 PM, Rich Bowen rbo...@rcbowen.com wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
1) snappy-java-1.0.4.1.jar is required when setting Snappy as a compression codec which is pulled from maven from ./sbt update and is Apache License 2.0 http://code.google.com/p/snappy-java/ 2) ZooKeeper client jar upgraded from 3.3.3 to 3.3.4 On Thu, Jun 21, 2012 at 2:32 PM, Chris Douglas cdoug...@apache.org wrote: Did these dependencies change between 0.7.0 and 0.7.1? -C On Wed, Jun 20, 2012 at 10:36 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jun 20, 2012, at 9:19 AM, Joe Stein wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). I need help checking these jars. What I recommend is that we update NOTICE in trunk as we attribute licenses to the jars below. This way we still vet the jars, update the NOTICE/LICENSE file in trunk for the next release, and not force Joe to cut a new release to include the updated NOTICE/LICENSE file. This will make subsequent releases go much easier. BTW, the keys and signatures are fine. Tests pass. (linkedin)[acabrera-mn:kafka-0.7.1-incubating 525]$ find . -name *.jar ./contrib/hadoop-consumer/lib/piggybank.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-el-1.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-net-1.4.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/core-3.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hadoop-core-0.20.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hsqldb-1.8.0.10.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-compiler-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-runtime-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jets3t-0.7.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-api-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/kfs-0.3.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/pig-0.8.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/xmlenc-0.52.jar ./contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.1.jar ./contrib/hadoop-producer/lib/piggybank.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.0.jar
[ANNOUNCE] Apache Airavata 0.3-INCUBATING Release
The Apache Airavata (Incubating) team is pleased to announce the immediate availability of the Airavata 0.3-INCUBATING release. The release can be obtained from the Apache Airavata download page - http://incubator.apache.org/airavata/about/downloads.html Release notes are available at - https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.3-incubating/RELEASE_NOTES Apache Airavata is a software toolkit currently used to build science gateways but that has a much wider potential use. It provides features to compose, manage, execute, and monitor small to large scale applications and workflows on computational resources ranging from local clusters to national grids and computing clouds. Gadgets interfaces to Airavata back end services can be deployed in open social containers such as Apache Rave and modify them to suit their needs. Airavata builds on general concepts of service oriented computing, distributed messaging, and workflow composition and orchestration. For general information on Apache Airavata, please visit the project website: http://incubator.apache.org/airavata/ Disclaimer: Apache Airavata is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
Not sure. It's simple enough to check the email archives for my last plea. With that said, I was hoping we could kill two birds with one stone. Regards, Alan On Jun 21, 2012, at 11:32 AM, Chris Douglas wrote: Did these dependencies change between 0.7.0 and 0.7.1? -C On Wed, Jun 20, 2012 at 10:36 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jun 20, 2012, at 9:19 AM, Joe Stein wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). I need help checking these jars. What I recommend is that we update NOTICE in trunk as we attribute licenses to the jars below. This way we still vet the jars, update the NOTICE/LICENSE file in trunk for the next release, and not force Joe to cut a new release to include the updated NOTICE/LICENSE file. This will make subsequent releases go much easier. BTW, the keys and signatures are fine. Tests pass. (linkedin)[acabrera-mn:kafka-0.7.1-incubating 525]$ find . -name *.jar ./contrib/hadoop-consumer/lib/piggybank.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-el-1.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-net-1.4.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/core-3.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hadoop-core-0.20.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hsqldb-1.8.0.10.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-compiler-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-runtime-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jets3t-0.7.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-api-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/kfs-0.3.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/pig-0.8.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/xmlenc-0.52.jar ./contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.1.jar ./contrib/hadoop-producer/lib/piggybank.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.0.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
On 06/21/2012 06:34 PM, Rich Bowen wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) +1 (non-binding). With regards, Daniel. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Jun 21, 2012, at 1:50 PM, Marvin Humphrey wrote: On Thu, Jun 21, 2012 at 6:15 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... I feel like I'm missing something. There shouldn't be any difference between a first-order dependency and a transitive dependency. All that matters is whether or not the dependency is bundled, right?[1] Why would we need ASF rules regarding *transitive* dependency license documentation in particular? Because Alan and I disagreed and nobody else had commented? ;-) So long as we bundle the bits, we have to bundle the licensing -- possibly bubbling up any relevant ALv2 NOTICE provisions into the top-level NOTICE since that's what the ALv2 requires. On the other hand, if the bits aren't bundled, then the licensing shouldn't be bundled either. If the bundled dependencies of the canonical ASF source release and a convenience binary differ, then their licensing must be analyzed separately and may differ. If a project has a gazillion dependencies, regardless of whether those dependencies are direct or transitive, that makes dealing with licensing more challenging, but it doesn't change our legal obligations. I think you and I agree. Though there may be some ambiguities in what we mean by direct or transitive dependencies. So, attempting to clarify: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). The Kafka LICENSE/NOTICE files only contain the licenses for this source code and the binary artifacts contained within the source release. They don't document the dependencies that they will bundle into a distribution. --kevan Marvin Humphrey [1] Leaving aside concerns about copyleft, field of use restrictions, etc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (binding) 2012/6/21 Rich Bowen rbo...@rcbowen.com: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Rich you need to requestg IPMC membership (was: Re: [VOTE] [PROPOSAL] Allura to enter the Incubator)
Rich, I note you mark your vote as non-binding. To be a champion/mentor you need to be an IPMC member. Since you are already an SF member you just need to ask and Jukka will sort it out. Sent from my mobile device, please forgive errors and brevity. On Jun 21, 2012 8:09 PM, Rich Bowen rbo...@rcbowen.com wrote: On Jun 21, 2012, at 12:34 PM, Rich Bowen wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) +1 (non-binding) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Rich you need to requestg IPMC membership (was: Re: [VOTE] [PROPOSAL] Allura to enter the Incubator)
On Jun 21, 2012, at 4:06 PM, Ross Gardler wrote: Rich, I note you mark your vote as non-binding. To be a champion/mentor you need to be an IPMC member. Since you are already an SF member you just need to ask and Jukka will sort it out. Ah. I didn't realize this. Jukka, can you hook me up? I'd like to request to be an IPMC member. Thank you. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Rich you need to requestg IPMC membership (was: Re: [VOTE] [PROPOSAL] Allura to enter the Incubator)
On Thu, Jun 21, 2012 at 4:06 PM, Ross Gardler rgard...@opendirective.com wrote: Rich, I note you mark your vote as non-binding. To be a champion/mentor you need to be an IPMC member. Since you are already an SF member you just need to ask and Jukka will sort it out. For the archives... it's his Apache membership that allows that to happen:) --tim - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (binding) On Thu, Jun 21, 2012 at 10:50 PM, Olivier Lamy ol...@apache.org wrote: +1 (binding) 2012/6/21 Rich Bowen rbo...@rcbowen.com: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
On Thu, Jun 21, 2012 at 10:35 PM, Daniel Gruno rum...@cord.dk wrote: On 06/21/2012 06:34 PM, Rich Bowen wrote: [ ] +1 I recommend that Allura becomes an Apache Incubator project +1 (binding) -- Best Regards, -- Alex
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
Great. We're not distributing the Snappy codec, so- according to the reasoning of board@, legal@, and the IPMC on the 0.7.0 release- the NOTICE and LICENSE files do not require updates. We're not starting from first principles at every release. I'm +1 on RC3. The LICENSE/NOTICE files contain the necessary citations for Nunit and sbt, the checksum and signature match, the DISCLAIMER is correct. -C On Thu, Jun 21, 2012 at 12:13 PM, Joe Stein crypt...@gmail.com wrote: 1) snappy-java-1.0.4.1.jar is required when setting Snappy as a compression codec which is pulled from maven from ./sbt update and is Apache License 2.0 http://code.google.com/p/snappy-java/ 2) ZooKeeper client jar upgraded from 3.3.3 to 3.3.4 On Thu, Jun 21, 2012 at 2:32 PM, Chris Douglas cdoug...@apache.org wrote: Did these dependencies change between 0.7.0 and 0.7.1? -C On Wed, Jun 20, 2012 at 10:36 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jun 20, 2012, at 9:19 AM, Joe Stein wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). I need help checking these jars. What I recommend is that we update NOTICE in trunk as we attribute licenses to the jars below. This way we still vet the jars, update the NOTICE/LICENSE file in trunk for the next release, and not force Joe to cut a new release to include the updated NOTICE/LICENSE file. This will make subsequent releases go much easier. BTW, the keys and signatures are fine. Tests pass. (linkedin)[acabrera-mn:kafka-0.7.1-incubating 525]$ find . -name *.jar ./contrib/hadoop-consumer/lib/piggybank.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-el-1.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-net-1.4.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/core-3.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hadoop-core-0.20.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hsqldb-1.8.0.10.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-compiler-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-runtime-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jets3t-0.7.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-api-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/kfs-0.3.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/pig-0.8.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (binding) On Thu, Jun 21, 2012 at 10:40 AM, Greg Stein gst...@gmail.com wrote: On Thu, Jun 21, 2012 at 12:34 PM, Rich Bowen rbo...@rcbowen.com wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) +1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
Thanks for the improvements Joe! I'm still -1 based on the licensing and binary artifacts in your source. (binding) --kevan On Jun 20, 2012, at 12:19 PM, Joe Stein wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). /* Joe Stein http://www.linkedin.com/in/charmalloc Twitter: @allthingshadoop http://www.twitter.com/allthingshadoop */ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
On Jun 21, 2012, at 4:36 PM, Chris Douglas wrote: Great. We're not distributing the Snappy codec, so- according to the reasoning of board@, legal@, and the IPMC on the 0.7.0 release- the NOTICE and LICENSE files do not require updates. We're not starting from first principles at every release. Care to provide some reference for the board@, legal@ reasoning? --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (non-binding) On 21/06/12 17:34, Rich Bowen wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Gary Martin gary.mar...@wandisco.com g...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller kevan.mil...@gmail.com wrote: If a project has a gazillion dependencies, regardless of whether those dependencies are direct or transitive, that makes dealing with licensing more challenging, but it doesn't change our legal obligations. I think you and I agree. Though there may be some ambiguities in what we mean by direct or transitive dependencies. By direct dependency, I meant a dependency where our code uses the dependency's API directly. By transitive dependency, I meant a dependency of a dependency: if A depends on B and B depends on C then A depends on C ... and thus C is a transitive dependency of A. I guess this transitive dependency terminology is a Maven thing. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies So, attempting to clarify: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. OK, that's what I was missing. :) If Kafka is indeed intended for use as an application/end-product, then it seems appropriate to document the licensing of unbundled dependencies -- but not legally mandatory since those bits aren't in the release artifacts. As someone who's not involved in Kafka, I don't feel it's my role to make the policy call as to whether the additional licensing info really ought to be there. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). /ASF Member hat on I agree with Roy that the ASF releases only source code, and that therefore binary files such as jars do not belong in our canonical source releases. The one TLP that I follow closely where this has been an issue with past releases has changed its way of doing things. I hope that other TLPs have made similar adaptations. /ASF Member hat off, IPMC Member hat on At the least, I don't think a podling ought to graduate if their releases contain binary artifacts. Problematic past practices of TLPs should not serve as precedents for podlings. /IPMC Member hat off As to whether this particular release should be blocked because there are jars in the source archive, I think it probably should, though I'm not planning to get involved in the VOTE. I'm sympathetic that Kafka drew the short straw before and got whipsawed during their first incubating release over NOTICE disagreements. (What was it -- 9, 10 release candidates?) However, I'm not how much flexibility we have with regards to the issue at hand. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
No. You have access to the same search functionality. Moreover, given the criteria that Kafka 0.7.0 was approved under, the burden of proof is on you to find references. Your musings on binaries are, as Martin pointed out, not legal arguments but preferences for clean downstream consumption. Even if I accept the goal, it is an insufficient reason for me to reverse my (binding) vote. The binary artifacts you refer to are jars from ASF projects and artifacts properly cited in the NOTICE/LICENSE files. The release is sound. You are, of course, welcome to vote against it because you believe that Kafka should go further, but the release violates no policy. -C On Thursday, June 21, 2012, Kevan Miller wrote: On Jun 21, 2012, at 4:36 PM, Chris Douglas wrote: Great. We're not distributing the Snappy codec, so- according to the reasoning of board@, legal@, and the IPMC on the 0.7.0 release- the NOTICE and LICENSE files do not require updates. We're not starting from first principles at every release. Care to provide some reference for the board@, legal@ reasoning? --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Allura to enter the Incubator
+1 (binding) On Jun 21, 2012, at 9:34 AM, Rich Bowen rbo...@rcbowen.com wrote: Hi, We are proposing Allura to be admitted to the Apache Incubator, and would like to request that the IPMC votes on this issue. The requisite 72 hours has passed since the initial proposal. The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal Please cast your vote. [ ] +1 I recommend that Allura becomes an Apache Incubator project [ ] 0 Abstain or don't care [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project yet (because ...) -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
Kevan, I agree that to the benefit of users, it would be reasonable for Apache projects to include license/notice for all dependant jars (directly or indirectly) in a release. However, this has to be done automatically by tools, not manually by human beings. IMO, without such tools, it's unfair (and error prone) to make this a requirement for all Apache projects. Thanks, Jun On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jun 21, 2012, at 1:50 PM, Marvin Humphrey wrote: On Thu, Jun 21, 2012 at 6:15 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... I feel like I'm missing something. There shouldn't be any difference between a first-order dependency and a transitive dependency. All that matters is whether or not the dependency is bundled, right?[1] Why would we need ASF rules regarding *transitive* dependency license documentation in particular? Because Alan and I disagreed and nobody else had commented? ;-) So long as we bundle the bits, we have to bundle the licensing -- possibly bubbling up any relevant ALv2 NOTICE provisions into the top-level NOTICE since that's what the ALv2 requires. On the other hand, if the bits aren't bundled, then the licensing shouldn't be bundled either. If the bundled dependencies of the canonical ASF source release and a convenience binary differ, then their licensing must be analyzed separately and may differ. If a project has a gazillion dependencies, regardless of whether those dependencies are direct or transitive, that makes dealing with licensing more challenging, but it doesn't change our legal obligations. I think you and I agree. Though there may be some ambiguities in what we mean by direct or transitive dependencies. So, attempting to clarify: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). The Kafka LICENSE/NOTICE files only contain the licenses for this source code and the binary artifacts contained within the source release. They don't document the dependencies that they will bundle into a distribution. --kevan Marvin Humphrey [1] Leaving aside concerns about copyleft, field of use restrictions, etc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On 22 June 2012 01:29, Jun Rao jun...@gmail.com wrote: Kevan, I agree that to the benefit of users, it would be reasonable for Apache projects to include license/notice for all dependant jars (directly or indirectly) in a release. However, this has to be done automatically by tools, not manually by human beings. IMO, without such tools, it's unfair (and error prone) to make this a requirement for all Apache projects. Note that the NL files only apply to the jars that are actually included in a release. So any automated solution needs to take account of whether the dependency is actually present or not. In fact dependencies are irrelevant here - what counts is presence in the release. One reason the NL files must agree with their contents is so the end-user knows what they are getting. It's important to provide full disclosure of the terms of all the components of the release. Thanks, Jun On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jun 21, 2012, at 1:50 PM, Marvin Humphrey wrote: On Thu, Jun 21, 2012 at 6:15 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... I feel like I'm missing something. There shouldn't be any difference between a first-order dependency and a transitive dependency. All that matters is whether or not the dependency is bundled, right?[1] Why would we need ASF rules regarding *transitive* dependency license documentation in particular? Because Alan and I disagreed and nobody else had commented? ;-) So long as we bundle the bits, we have to bundle the licensing -- possibly bubbling up any relevant ALv2 NOTICE provisions into the top-level NOTICE since that's what the ALv2 requires. On the other hand, if the bits aren't bundled, then the licensing shouldn't be bundled either. If the bundled dependencies of the canonical ASF source release and a convenience binary differ, then their licensing must be analyzed separately and may differ. If a project has a gazillion dependencies, regardless of whether those dependencies are direct or transitive, that makes dealing with licensing more challenging, but it doesn't change our legal obligations. I think you and I agree. Though there may be some ambiguities in what we mean by direct or transitive dependencies. So, attempting to clarify: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). The Kafka LICENSE/NOTICE files only contain the licenses for this source code and the binary artifacts contained within the source release. They don't document the dependencies that they will bundle into a distribution. --kevan Marvin Humphrey [1] Leaving aside concerns about copyleft, field of use restrictions, etc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
Hi, Jun, On Thu, Jun 21, 2012 at 5:29 PM, Jun Rao jun...@gmail.com wrote: I agree that to the benefit of users, it would be reasonable for Apache projects to include license/notice for all dependant jars (directly or indirectly) in a release. However, this has to be done automatically by tools, not manually by human beings. IMO, without such tools, it's unfair (and error prone) to make this a requirement for all Apache projects. Obeying dependency license provisions is not an ASF policy, it's a legal requirement. Fairness is immaterial. If you bundle the bits, you must deal with the licensing and you must get it right. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
+1 on the release. Run quickstart and unit tests. All good. Thanks, Jun On Wed, Jun 20, 2012 at 9:19 AM, Joe Stein crypt...@gmail.com wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). /* Joe Stein http://www.linkedin.com/in/charmalloc Twitter: @allthingshadoop http://www.twitter.com/allthingshadoop */
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Thu, Jun 21, 2012 at 5:42 PM, Marvin Humphrey mar...@rectangular.com wrote: Obeying dependency license provisions is not an ASF policy, it's a legal requirement. Fairness is immaterial. If you bundle the bits, you must deal with the licensing and you must get it right. Sure, but that's not an issue here. The legal requirements are satisfied, as was established at length during the Kafka 0.7.0 release. -C - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
On Thu, Jun 21, 2012 at 4:27 PM, Chris Douglas cdoug...@apache.org wrote: Your musings on binaries are, as Martin pointed out, not legal arguments but preferences for clean downstream consumption. I think there's been a miscommunication. Kevan and I may place different weight on documenting licensing for non-bundled dependencies, but that's not the only issue -- there are binary files in Kafka's canonical source release candidate, and I agree with Kevan that this is a problem. marvin@smokey:~/Desktop/kafka $ find . -print | grep \.jar ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar ./contrib/hadoop-consumer/lib/piggybank.jar ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar ./contrib/hadoop-producer/lib/piggybank.jar ./lib/sbt-launch.jar It would be unfortunate to draw a line in the sand over Kafka, when they are hardly the only project where this has been an issue and when the NOTICE debate over Kafka 0.7.0 was draining. At some point, though, IPMC members either need to start voting -1 on any incubating RC that has a jar file in it, or someone needs to formally answer Roy's argument and explain how binary files can be considered open source when they aren't source code. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Jun 21, 2012, at 12:35 PM, Kevan Miller wrote: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. Dependencies do matter and they need to be checked. IMO, that point is non-negotiable. The point that I'm trying to make is that the *documentation* of these dependencies in the LICENSE and NOTICE is what is vague in the rules. The previous Kafka release did no such documentation and I'm certain other projects have done this as well. With that said, I am of the same opinion as you, Kevan, and think that they should be documented in LICENSE and NOTICE. However, I don't think that it should hold up this release. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). The Kafka LICENSE/NOTICE files only contain the licenses for this source code and the binary artifacts contained within the source release. They don't document the dependencies that they will bundle into a distribution.
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Jun 21, 2012, at 3:33 PM, Marvin Humphrey wrote: So, attempting to clarify: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. OK, that's what I was missing. :) If Kafka is indeed intended for use as an application/end-product, then it seems appropriate to document the licensing of unbundled dependencies -- but not legally mandatory since those bits aren't in the release artifacts. As someone who's not involved in Kafka, I don't feel it's my role to make the policy call as to whether the additional licensing info really ought to be there. Agreed, it should be in there, not must be in there. If others feel differently then they are free to ratify a new rule about this. Piggy backing refinements in policy on top of votes is, IMO, one the biggest frustrations podlings have with the Incubator. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). /ASF Member hat on I agree with Roy that the ASF releases only source code, and that therefore binary files such as jars do not belong in our canonical source releases. The one TLP that I follow closely where this has been an issue with past releases has changed its way of doing things. I hope that other TLPs have made similar adaptations. /ASF Member hat off, IPMC Member hat on /ASF Member hat on :) It's my understanding that there are other graduated projects that distribute jars w/ their source code. With that said, the statement jars do not belong in our canonical source releases strikes as an aesthetic statement. Sometimes, it's required because of the way the project build system is organized. /ASF Member hat off, IPMC Member hat on :) At the least, I don't think a podling ought to graduate if their releases contain binary artifacts. Problematic past practices of TLPs should not serve as precedents for podlings. Oh, but past practices are used to justify all sorts of things here at ASF. If there is no concrete rule prohibiting it. If you and Kevan feel strongly about it I invite you to join the project and update it yourselves. This is, of course, open source. ;) /IPMC Member hat off As to whether this particular release should be blocked because there are jars in the source archive, I think it probably should, though I'm not planning to get involved in the VOTE. I'm sympathetic that Kafka drew the short straw before and got whipsawed during their first incubating release over NOTICE disagreements. (What was it -- 9, 10 release candidates?) However, I'm not how much flexibility we have with regards to the issue at hand. I think that it warrants saying again, piggy backing refinements in policy on top of votes is, IMO, one the biggest frustrations podlings have with the Incubator. If you feel strongly about a refinement then start and manage its ratification on general@i.a.o or members@a.o *on its own separate thread*. If you feel strongly about how a project's build is organized, roll up your sleeves and join in on the fun. Regards, Alan
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
+1 If this is going to be a new hard requirement the people who feel strongly about this should add something to Rat or write some kind of a plugin. Regards, Alan On Jun 21, 2012, at 5:29 PM, Jun Rao wrote: Kevan, I agree that to the benefit of users, it would be reasonable for Apache projects to include license/notice for all dependant jars (directly or indirectly) in a release. However, this has to be done automatically by tools, not manually by human beings. IMO, without such tools, it's unfair (and error prone) to make this a requirement for all Apache projects. Thanks, Jun On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jun 21, 2012, at 1:50 PM, Marvin Humphrey wrote: On Thu, Jun 21, 2012 at 6:15 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: With that said, I think it's something good and extremely useful to strive for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with regards to transitive dependencies, is not a showstopper IMO unless there are explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... I feel like I'm missing something. There shouldn't be any difference between a first-order dependency and a transitive dependency. All that matters is whether or not the dependency is bundled, right?[1] Why would we need ASF rules regarding *transitive* dependency license documentation in particular? Because Alan and I disagreed and nobody else had commented? ;-) So long as we bundle the bits, we have to bundle the licensing -- possibly bubbling up any relevant ALv2 NOTICE provisions into the top-level NOTICE since that's what the ALv2 requires. On the other hand, if the bits aren't bundled, then the licensing shouldn't be bundled either. If the bundled dependencies of the canonical ASF source release and a convenience binary differ, then their licensing must be analyzed separately and may differ. If a project has a gazillion dependencies, regardless of whether those dependencies are direct or transitive, that makes dealing with licensing more challenging, but it doesn't change our legal obligations. I think you and I agree. Though there may be some ambiguities in what we mean by direct or transitive dependencies. So, attempting to clarify: I think Alan's (Kafka's) position is that dependencies don't matter since they are not distributing binary artifacts. I would agree with Alan, if Kafka source was simply intended to be used in source form. That's not the case. The Kafka project is designed to be built/compiled into a distribution. So, IMO, Kafka must document their dependencies. Note that if Kafka only had compile-time/test-time dependencies and simply built .jar files (and someone else was responsible for bundling everything together into a distribution), then I'd have a different opinion. In this case, the Kafka source release contains AL v2 licensed source code along with some binary artifacts under several licenses (you're welcome to comment on this, also). The Kafka LICENSE/NOTICE files only contain the licenses for this source code and the binary artifacts contained within the source release. They don't document the dependencies that they will bundle into a distribution. --kevan Marvin Humphrey [1] Leaving aside concerns about copyleft, field of use restrictions, etc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
On Jun 21, 2012, at 5:45 PM, Chris Douglas wrote: On Thu, Jun 21, 2012 at 5:42 PM, Marvin Humphrey mar...@rectangular.com wrote: Obeying dependency license provisions is not an ASF policy, it's a legal requirement. Fairness is immaterial. If you bundle the bits, you must deal with the licensing and you must get it right. Sure, but that's not an issue here. The legal requirements are satisfied, as was established at length during the Kafka 0.7.0 release. -C This reflects my sentiments as well. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
On Jun 21, 2012, at 6:27 PM, Marvin Humphrey wrote: At some point, though, IPMC members either need to start voting -1 on any incubating RC that has a jar file in it, or someone needs to formally answer Roy's argument and explain how binary files can be considered open source when they aren't source code. Roy's missives are not papal bulls. He is entitled to espouse his opinion and I am entitled to not read it; though I almost always do. :) My point is that we need something more formal than digging through yards of drivel to find nuggets of real discussion that don't amount to pleas to be emotionally validated. Even then, just because someone espouses an opinion it does not become law because others have stopped replying, implying lazy consensus where sometimes it's really that opposing opinions walked or were bullied away. Really, we need something more formal. Lite, but formal. Regards, Alan
Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
It's the PPMC's job to vet these dependencies, not the mentors. I already did this once after no one answered my request for help during the 0.7.0 vote. Someone from the Kafka PPMC needs to step up. My vote will depend on the outcome of this check. BTW, there's a number of duplicate jars. Not sure if that will be a problem. Regards, Alan On Jun 21, 2012, at 12:31 PM, Alan D. Cabrera wrote: Not sure. It's simple enough to check the email archives for my last plea. With that said, I was hoping we could kill two birds with one stone. Regards, Alan On Jun 21, 2012, at 11:32 AM, Chris Douglas wrote: Did these dependencies change between 0.7.0 and 0.7.1? -C On Wed, Jun 20, 2012 at 10:36 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jun 20, 2012, at 9:19 AM, Joe Stein wrote: Hello, This is the third candidate for the second incubator release for Apache Kafka, version 0.7.1-incubating. This release fixes the following issues http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3/RELEASE-NOTES.html Release artifacts: http://people.apache.org/~joestein/kafka-0.7.1-incubating-candidate-3 The tag to be voted upon (off the 0.7.1 branch): https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.1-incubating-candidate-3/ Kafka's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/kafka/KEYS The vote will be open for 72 hours (longer if needed). I need help checking these jars. What I recommend is that we update NOTICE in trunk as we attribute licenses to the jars below. This way we still vet the jars, update the NOTICE/LICENSE file in trunk for the next release, and not force Joe to cut a new release to include the updated NOTICE/LICENSE file. This will make subsequent releases go much easier. BTW, the keys and signatures are fine. Tests pass. (linkedin)[acabrera-mn:kafka-0.7.1-incubating 525]$ find . -name *.jar ./contrib/hadoop-consumer/lib/piggybank.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/ant-1.6.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/asm-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/avro-1.3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-cli-1.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.4.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-el-1.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-net-1.4.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/core-3.1.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hadoop-core-0.20.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/hsqldb-1.8.0.10.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.4.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-compiler-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jasper-runtime-5.5.12.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jets3t-0.7.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jsp-api-2.1-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/kfs-0.3.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/pig-0.8.0.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-6.1.14.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/xmlenc-0.52.jar ./contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.1.jar ./contrib/hadoop-producer/lib/piggybank.jar
