Re: [PROPOSAL] Apache Argus Proposal
How do you define the 'Hadoop complex eco-system'? If that definition Agreed, complex is a relative term. I used the term complex, because now more than 20 products use Hadoop and list is growing. There are 10 products listed on http://hadoop.apache.org/. Then there are others projects like Accumulo, Impala, Storm, Kafka, Falcon, Pig, Flume, Sqoop, Oozie, etc. which uses HDFS or support/enable other products within Hadoop ecosystem. If we dig deeper, each component might have multiple processes (Name Node, Data Node, Job Tracker, Storm Nimbus Server, HBase Master Servers, HBase Regions Servers, HA, etc). With YARN, now user can run their applications in the cluster, which is a great feature, but it is very scary from security point of view, because now users can write their custom application and run it within a secure data center. I don’t feel one technology or one company or one small group or one approach can solve this problem. This has to be addressed by the community working together. This would also require a lot of support from each dependent projects and lot of co-ordination. And there would be multiple security solutions available for the end users to pick from. includes projects such as HBase, we have significant security controls, so The mature projects have started beefing up their security features. In recent releases, HBase added cell based access control and encryption, HDFS added advanced ACLs and now working on file level encryptions, Hive added ATZ-NG, no encryption yet. The newer ones like Solr, Storm, Falcon have very basic security control. On the good news side, most components have started supporting Kerberos and SSL. But encryption at rest is still a challenge. In most cases it is all or none, except probably HBase and Accumulo. Access control and auditing is also not that mature among the newer projects. The goal is here is not to reinvent or impose on each project, but to reuse the existing security technologies consistently across projects and at the same extend it where applicable. or the combination of Hive+Sentry would agree with that statement either. Personally, Hive is my ideal role model for all hadoop projects to follow. Out of the box, it has inbuilt access control, but also provides APIs to plug your authorization model. Now security projects like Argus can extend it to support attribute based access control, cell based access control, tagging, multi-tenancy, auditing, etc. Users based on their security requirement or appetite might decide to go with the default or choose one of the other security providers. Similar requirements might be there for HBase, but expecting all Hadoop components to keep up with each other is counter productive, while a dedicated security provider (project) might do more extensive and uniform job. Users might also pick multiple security providers within their cluster to address specific security concerns. Since we are on the topic of complexity, one of the reason Hadoop is popular is because of its openness. Hive might be on top of anything, e.g. on HDFS, HBase+HDFS, flat file, etc. While you can access SQL queries via Hive, you can also write Pig or MR job to access the underlying HDFS file directly. This is a powerful feature, which now gives them ability to run sophisticated analytical jobs or use enterprise grade BI tool. But this also allows users to circumvent Hive’s native security. For Hive or any native component, cross component security is out of scope (and should be). This problem can be solved by security providers like Argus, who can enforce adequate security consistently across components or project boundaries. Happy to discuss more on this topic. Thanks Bosco On Jul 16, 2014, at 7:38 PM, Andrew Purtell apurt...@apache.org wrote: This statement might not be quite right: Even within Hadoop complex eco-system, each components have limited or no security controls. How do you define the 'Hadoop complex eco-system'? If that definition includes projects such as HBase, we have significant security controls, so that wouldn't be a correct statement. Not sure those working on Accumulo, or the combination of Hive+Sentry would agree with that statement either. It's not necessary to survey the Hadoop ecosystem before incubating of course, or even after, but it sounds like that might be a good idea. On Wed, Jul 16, 2014 at 5:06 PM, Don Bosco Durai bdu...@hortonworks.com wrote: Hi JB We will be centralizing the administration and auditing for Knox. And we will be also standardizing the authentication for web applications for all components within Hadoop ecosystem, for which we might consider Shiro. I would like to understand more about Syncope and see how production ready it is... The principle is to leverage existing security solutions where applicable. Even within Hadoop complex eco-system, each components have limited or no security controls.
Re: Reviewing license / notice and bundled software
When I did this review for Spark, I used Maven's license plugin: http://mojo.codehaus.org/license-maven-plugin/ mvn license:aggregate-add-third-party It creates a report of all transitive deps and their license, according to pom files. I had to indeed review lots of the dependencies by hand to evaluate license issues. It is not simple. On Thu, Jul 17, 2014 at 1:19 AM, Justin Mclean jus...@classsoftware.com wrote: Hi, Last few times I've reviewed LICENSE / NOTICE files in projects it ends up being quite difficult knowing what exactly has been bundled and exactly how those bits of included software are licensed. In particular some software (i.e. bootstap) have moved form an Apache license to an MIT one in recent times and it not always immediately clear which version has been bundled. So what the the best way for projects to indicate what versions of software (and what licences) have been bundled and to make reviewing LICENSE/NOTICE easier? IMO this helps both the incubator (more people vote/less issues get through) and incubating projects (less -1s due to LICENSE/NOTICE issues). In particular bundled Apache licensed software is an issue. How do you easily tell the difference between a a missing entry to LICENSE (as the bundled software may be say BSD or MIT license) vs nothing required in LICENSE as the bundled software is Apache licence? In some cases searching for file headers can help but quite often they are missing and/or it not immediately obvious what terms an external projects is licensed under. Thanks, Justin - 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: Reviewing license / notice and bundled software
Hi, I had to indeed review lots of the dependencies by hand to evaluate license issues. It is not simple. it certainly can be complex but just wondering if we can make the more reasonable cases easier to review / easier for incubator projects. Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reviewing license / notice and bundled software
Hi doesn't http://creadur.apache.org/ helps? I in particular thinks to http://creadur.apache.org/tentacles/ If there is no bundle it doesn't solve the whole issue but that's our code so we can enhance it to support maven more deeply. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-07-17 11:59 GMT+02:00 Justin Mclean jus...@classsoftware.com: Hi, I had to indeed review lots of the dependencies by hand to evaluate license issues. It is not simple. it certainly can be complex but just wondering if we can make the more reasonable cases easier to review / easier for incubator projects. Justin - 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: Reviewing license / notice and bundled software
Are you using RAT to evaluate releases for licenses? Or are you doing pre-release activities? RAT will look at every file in a release and try to identify the license. Are you looking for something that RAT can't do? Craig On Jul 17, 2014, at 2:59 AM, Justin Mclean wrote: Hi, I had to indeed review lots of the dependencies by hand to evaluate license issues. It is not simple. it certainly can be complex but just wondering if we can make the more reasonable cases easier to review / easier for incubator projects. Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reviewing license / notice and bundled software
I guess it is about mvn dependency:tree analysis. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-07-17 16:17 GMT+02:00 Craig L Russell craig.russ...@oracle.com: Are you using RAT to evaluate releases for licenses? Or are you doing pre-release activities? RAT will look at every file in a release and try to identify the license. Are you looking for something that RAT can't do? Craig On Jul 17, 2014, at 2:59 AM, Justin Mclean wrote: Hi, I had to indeed review lots of the dependencies by hand to evaluate license issues. It is not simple. it certainly can be complex but just wondering if we can make the more reasonable cases easier to review / easier for incubator projects. Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - 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: [PROPOSAL] Apache Argus Proposal
Thank you for writing back with a detailed clarification. Regarding encryption at rest, HDFS is adding it as HDFS-6134, so likely there will be a new core feature option for the ecosystem to consider shortly. I don’t feel one technology or one company or one small group or one approach can solve this problem. This has to be addressed by the community working together. This would also require a lot of support from each dependent projects and lot of co-ordination. And there would be multiple security solutions available for the end users to pick from. Completely agreed. However, the desired community cooperation has both technical and political components. I think there are some concerns about how successful an outcome Argus may produce, informed by experience. Perhaps it would be worthwhile to address those concerns. Argus proposes to develop a common security infrastructure for the Hadoop ecosystem. In my opinion (and informed by personal experience) we have new incubating Hadoop ecosystem security projects like Sentry and Knox and proposals such as Argus because Hadoop core is locked down. Argus et. al. are like the proverbial blocked river (user demand for features) seeking a new route around a landslide (obvious poisonous contention and litigation-via-JIRA on every significant topic). I would be curious your thoughts on how to avoid the same end state in the Argus project. In my opinion, it would be a tragedy if a potential solution ends up perpetuating the dysfunction it seeks to bypass to a greater proportion of Foundation projects instead. A Hadoop ecosystem project attempting to remain independent from the dysfunction of Hadoop core would be well advised to stay away from adoption of Argus components (security is so critical) if the governance of Argus perpetuates that dysfunction. By the way, it is also not too late for Knox and Sentry. On Wed, Jul 16, 2014 at 11:34 PM, Don Bosco Durai bdu...@hortonworks.com wrote: How do you define the 'Hadoop complex eco-system'? If that definition Agreed, complex is a relative term. I used the term complex, because now more than 20 products use Hadoop and list is growing. There are 10 products listed on http://hadoop.apache.org/. Then there are others projects like Accumulo, Impala, Storm, Kafka, Falcon, Pig, Flume, Sqoop, Oozie, etc. which uses HDFS or support/enable other products within Hadoop ecosystem. If we dig deeper, each component might have multiple processes (Name Node, Data Node, Job Tracker, Storm Nimbus Server, HBase Master Servers, HBase Regions Servers, HA, etc). With YARN, now user can run their applications in the cluster, which is a great feature, but it is very scary from security point of view, because now users can write their custom application and run it within a secure data center. I don’t feel one technology or one company or one small group or one approach can solve this problem. This has to be addressed by the community working together. This would also require a lot of support from each dependent projects and lot of co-ordination. And there would be multiple security solutions available for the end users to pick from. includes projects such as HBase, we have significant security controls, so The mature projects have started beefing up their security features. In recent releases, HBase added cell based access control and encryption, HDFS added advanced ACLs and now working on file level encryptions, Hive added ATZ-NG, no encryption yet. The newer ones like Solr, Storm, Falcon have very basic security control. On the good news side, most components have started supporting Kerberos and SSL. But encryption at rest is still a challenge. In most cases it is all or none, except probably HBase and Accumulo. Access control and auditing is also not that mature among the newer projects. The goal is here is not to reinvent or impose on each project, but to reuse the existing security technologies consistently across projects and at the same extend it where applicable. or the combination of Hive+Sentry would agree with that statement either. Personally, Hive is my ideal role model for all hadoop projects to follow. Out of the box, it has inbuilt access control, but also provides APIs to plug your authorization model. Now security projects like Argus can extend it to support attribute based access control, cell based access control, tagging, multi-tenancy, auditing, etc. Users based on their security requirement or appetite might decide to go with the default or choose one of the other security providers. Similar requirements might be there for HBase, but expecting all Hadoop components to keep up with each other is counter productive, while a dedicated security provider (project) might do more extensive and uniform job. Users might also pick multiple security providers within their cluster to address specific security concerns. Since we are on the topic of complexity, one of the reason
Re: [PROPOSAL] Apache Argus Proposal
Andrews, thanks for your feedback. My responses are inline. Regards Bosco On Jul 17, 2014, at 11:41 AM, Andrew Purtell apurt...@apache.org wrote: Thank you for writing back with a detailed clarification. Regarding encryption at rest, HDFS is adding it as HDFS-6134, so likely there will be a new core feature option for the ecosystem to consider shortly. I don’t feel one technology or one company or one small group or one approach can solve this problem. This has to be addressed by the community working together. This would also require a lot of support from each dependent projects and lot of co-ordination. And there would be multiple security solutions available for the end users to pick from. Completely agreed. However, the desired community cooperation has both technical and political components. I think there are some concerns about how successful an outcome Argus may produce, informed by experience. Perhaps it would be worthwhile to address those concerns. Argus proposes to The current Argus solution already has integration with the core Hadoop components like HDFS, Hive and HBase. There are work in progress to support additional Hadoop components, which includes Knox. Anytime, we cross project boundaries, there were would be always challenges wrt technical and political. Working this out within the community makes more sense, rather than doing this outside. Not attempting would be counterproductive. develop a common security infrastructure for the Hadoop ecosystem. In my opinion (and informed by personal experience) we have new incubating Hadoop ecosystem security projects like Sentry and Knox and proposals such as Argus because Hadoop core is locked down. Argus et. al. are like the proverbial blocked river (user demand for features) seeking a new route around a landslide (obvious poisonous contention and litigation-via-JIRA on every significant topic). I would be curious your thoughts on how to avoid the same end state in the Argus project. In my opinion, it would be a tragedy if a potential solution ends up perpetuating the dysfunction it seeks to bypass to a greater proportion of Foundation projects instead. A Hadoop ecosystem project attempting to remain independent from the dysfunction of Hadoop core would be well advised to stay away from adoption of Argus components (security is so critical) if the governance of Argus I don’t believe Argus existence is because HDFS or any other component is locked down or dysfunctional. Each component will continue to evolve (core features and security) overtime based on their priority, severity and timeline. The option to externalize security is always a good thing. Option to externalize is a well accepted notion in the community. Commercial databases allow externalizing security, web applications externalize authentication and authorization, there are vulnerability management systems for file system/software version, etc. I don’t see a security provider like Argus or Sentry extending the native security as a risk or bad thing, instead, a good motivation for projects (particularly new) to focus on their core features. I also don’t feel this is a short term user demand. Security requirement changes on regular basis and as different type of industries adopt hadoop, their security requirements might be also different. They will look for different options for security and select what addresses their needs. perpetuates that dysfunction. By the way, it is also not too late for Knox and Sentry. Security is most effective when it is deployed as layered solution. Knox addresses the perimeter security. Currently it is REST and they will extend it to support security for more external API technologies. Argus will not replace it, but complement Knox by centralizing the administration and common auditing. Sentry and Argus have some overlap, but at the core, they have different philosophies and approach. Similar discussion can be made between no-sql projects like Apache HBase, Apache Accumulo and Apache Cassandra. Varying options is always healthy. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Apache Slider 0.40-incubating RC0
Hello, This is a call for a vote on Apache Slider 0.40.0 incubating release. Thanks to everyone who have contributed to this release. A vote was held on the developer mailing list and it passed with 5 +1s. http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201407.mbox/%3CCABCXrRT2GgfTogkWzCghi1NcLm18ydp7W2MbQ4PrR73EqODODg%40mail.gmail.com%3E Git source tag: https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=shortlog;h=refs/tags/release-0.40.0-rc0 Staging site: http://people.apache.org/~smohanty/slider-release-0.40.0-rc0 PGP release keys (signed using 791FDAB0) http://pgp.mit.edu/pks/lookup?op=vindexsearch=0xECFC8276791FDAB0 One can look into the issues fixed in this release at: https://issues.apache.org/jira/browse/SLIDER/fixforversion/12326825 Note that this is a source only release and we are voting on the source. (One .tar file, appdef_1.tar, is a text file used for -ve testing) Build instructions at: http://slider.incubator.apache.org/developing/building.html Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) thanks Sumit
Re: [VOTE] Apache Slider 0.40-incubating RC0
+1 binding - verified signature and checksums, verified licenses, built from source and ran tests On Thu, Jul 17, 2014 at 1:16 PM, Sumit Mohanty smoha...@apache.org wrote: Hello, This is a call for a vote on Apache Slider 0.40.0 incubating release. Thanks to everyone who have contributed to this release. A vote was held on the developer mailing list and it passed with 5 +1s. http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201407.mbox/%3CCABCXrRT2GgfTogkWzCghi1NcLm18ydp7W2MbQ4PrR73EqODODg%40mail.gmail.com%3E Git source tag: https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=shortlog;h=refs/tags/release-0.40.0-rc0 Staging site: http://people.apache.org/~smohanty/slider-release-0.40.0-rc0 PGP release keys (signed using 791FDAB0) http://pgp.mit.edu/pks/lookup?op=vindexsearch=0xECFC8276791FDAB0 One can look into the issues fixed in this release at: https://issues.apache.org/jira/browse/SLIDER/fixforversion/12326825 Note that this is a source only release and we are voting on the source. (One .tar file, appdef_1.tar, is a text file used for -ve testing) Build instructions at: http://slider.incubator.apache.org/developing/building.html Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) thanks Sumit
Re: Reviewing license / notice and bundled software
Hi, Are you using RAT to evaluate releases for licenses? Or are you doing pre-release activities? Apache Rat is a great help and certainly points you in the right direction. But even then a lot of the time you have to go and manually check if something been Apache licensed or not, or try and determine exactly what version of something has been bundled. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Argus Proposal
Working this out within the community makes more sense, rather than doing this outside. Not attempting would be counterproductive. Does this not argue directly against the rationale of the Argus proposal? Please correct me if I am wrong, but this suggests addressing security concerns within existing Hadoop ecosystem communities rather than attempting an overlay project. This applies equally to Sentry, on its current trajectory, by the way. The option to externalize security is always a good thing. A contradiction with the above? But I agree that having a trustworthy option would be fantastic. Option to externalize is a well accepted notion in the community. Commercial databases allow externalizing security, web applications externalize authentication and authorization, there are vulnerability management systems for file system/software version, etc. I don’t see a security provider like Argus or Sentry extending the native security as a risk or bad thing, instead, a good motivation for projects (particularly new) to focus on their core features. Concerns about starting a new community from a position of a lack of trust are ignored to the peril of this stated goal. I think Argus - or any project with aims to discuss, and ultimately convince, other projects to externalize a core matter like security - will fail to make their case if there is perceived risk. Any perceived risk will be proportional to lack of trust in the integrity, openness, and healthy function of an Argus PMC and community processes. We can ignore the elephant in the room, so to speak, and pretend like this proposal drops in out of the blue sky, but clear thinking individuals to whom you are making your case for externalization of security features at a later time will not. Establishing trust and a track record of inclusion and openness will be essential for Argus to achieve your objectives, if I understand them correctly. I encourage you to address concerns raised on this thread about the complexion of the initial PMC and mentorships. There have been a few suggestions worth exploring. Similar discussion can be made between no-sql projects like Apache HBase, Apache Accumulo and Apache Cassandra. Not similar at all. This isn't about choice, this is about trust. Security and trust are wedded inseparably. On Thu, Jul 17, 2014 at 1:03 PM, Don Bosco Durai bdu...@hortonworks.com wrote: Andrews, thanks for your feedback. My responses are inline. Regards Bosco On Jul 17, 2014, at 11:41 AM, Andrew Purtell apurt...@apache.org wrote: Thank you for writing back with a detailed clarification. Regarding encryption at rest, HDFS is adding it as HDFS-6134, so likely there will be a new core feature option for the ecosystem to consider shortly. I don’t feel one technology or one company or one small group or one approach can solve this problem. This has to be addressed by the community working together. This would also require a lot of support from each dependent projects and lot of co-ordination. And there would be multiple security solutions available for the end users to pick from. Completely agreed. However, the desired community cooperation has both technical and political components. I think there are some concerns about how successful an outcome Argus may produce, informed by experience. Perhaps it would be worthwhile to address those concerns. Argus proposes to The current Argus solution already has integration with the core Hadoop components like HDFS, Hive and HBase. There are work in progress to support additional Hadoop components, which includes Knox. Anytime, we cross project boundaries, there were would be always challenges wrt technical and political. Working this out within the community makes more sense, rather than doing this outside. Not attempting would be counterproductive. develop a common security infrastructure for the Hadoop ecosystem. In my opinion (and informed by personal experience) we have new incubating Hadoop ecosystem security projects like Sentry and Knox and proposals such as Argus because Hadoop core is locked down. Argus et. al. are like the proverbial blocked river (user demand for features) seeking a new route around a landslide (obvious poisonous contention and litigation-via-JIRA on every significant topic). I would be curious your thoughts on how to avoid the same end state in the Argus project. In my opinion, it would be a tragedy if a potential solution ends up perpetuating the dysfunction it seeks to bypass to a greater proportion of Foundation projects instead. A Hadoop ecosystem project attempting to remain independent from the dysfunction of Hadoop core would be well advised to stay away from adoption of Argus components (security is so critical) if the governance of Argus I don’t believe Argus existence is because HDFS or any other component is locked down or dysfunctional. Each component will continue to
Re: [PROPOSAL] Apache Argus Proposal
On Thu, Jul 17, 2014 at 2:42 PM, Andrew Purtell apurt...@apache.org wrote: Establishing trust and a track record of inclusion and openness will be essential for Argus to achieve your objectives, if I understand them correctly. I encourage you to address concerns raised on this thread about the complexion of the initial PMC and mentorships. Andrew, I agree that security project even more than typical open source projects, trust in the development community is critical. We will do our best to earn the trust and support of the community. Obviously, the proposal is very up-front about the lack of diversity in the committer list. It however, reflects the reality of the current project. We are very interested in inclusively enlarging the development community for the project after the initial code drop to Apache gets us off the ground. .. Owen
[NOTICE] George Reyes for Usergrid Committership
Hi IPMC, The Usergrid (Incubating) PPMC have VOTE'd to add George Reyes to join Usergrid and obtain Committership rights. VOTE: *http://s.apache.org/jF1 http://s.apache.org/jF1* RESULTS: *http://s.apache.org/Amf http://s.apache.org/Amf* Thank you Lewis On Behalf of Usergrid PPMC -- _ _ _ _ _ ___ _ _ _ _ _ |_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___ | | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | | |_| |_|_|___| |__|__| _|__,|___|_|_|___| |_|___|_| |_| |_|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_| |_| http://people.apache.org/~lewismc || @hectorMcSpector || http://www.linkedin.com/in/lmcgibbney Apache Gora V.P || Apache Nutch PMC || Apache Any23 V.P || Apache OODT PMC || Apache TAC
Re: [VOTE] Apache Slider 0.40-incubating RC0
Hi, A vote was held on the developer mailing list and it passed with 5 +1s. http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201407.mbox/%3CCABCXrRT2GgfTogkWzCghi1NcLm18ydp7W2MbQ4PrR73EqODODg%40mail.gmail.com%3E A [VOTE][RESULT] would be nice to have. How many of those votes are binding? (by my count looks like 4 not 5). Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Slider 0.40-incubating RC0
Here is the result thread. http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201407.mbox/%3CCABCXrRRR-NkJfy65Hw2sxqHO7D4HFJEWWWmP_sycGoasUWLwqA%40mail.gmail.com%3E And, you are right, its 5 +1 votes with 4 of them binding. *I guess I am still learning the specifics.* thanks -Sumit On Thu, Jul 17, 2014 at 3:17 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, A vote was held on the developer mailing list and it passed with 5 +1s. http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201407.mbox/%3CCABCXrRT2GgfTogkWzCghi1NcLm18ydp7W2MbQ4PrR73EqODODg%40mail.gmail.com%3E A [VOTE][RESULT] would be nice to have. How many of those votes are binding? (by my count looks like 4 not 5). Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Reviewing license / notice and bundled software
Hi, Lets take for instance slider as they have just put up an RC for voting. Slider bundles a few things and may have some Apache Licensed software bundled. Can you tell easily what those bits are? And if so what versions? Source headers here are no help as all Apache source headers are the same. While no changes to LICENSE would be required for Apache bundled software, there may be missing items from the NOTICE file if you bundled software also has NOTICE files. BTW I don't think there is any issue with the RC in this case but it's hard to determine without a list of what has been bundled. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Slider 0.40-incubating RC0
Hi, +1 binding - Vote passed - incubating in release name - signatures and hashes correct - DISCLAIMER exits - LICENSE and NOTICE good - No binary files in source release - all source files have correct headers - can compile from source I did notice one little odd thing and it's probably nothing, but just in case: In LICENSE you mention Kokki (BSD license) but all files under slider-agent/src/main/python/resource_management seem to have Apache headers. Should any files have BSD headers? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Slider 0.40-incubating RC0
+1 binding. Signature/required files/headers/hashes all look good. -jakob On Thu, Jul 17, 2014 at 6:18 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, +1 binding - Vote passed - incubating in release name - signatures and hashes correct - DISCLAIMER exits - LICENSE and NOTICE good - No binary files in source release - all source files have correct headers - can compile from source I did notice one little odd thing and it's probably nothing, but just in case: In LICENSE you mention Kokki (BSD license) but all files under slider-agent/src/main/python/resource_management seem to have Apache headers. Should any files have BSD headers? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Slider 0.40-incubating RC0
Thanks Justin. The Kokki files (https://github.com/samuel/kokki/tree/master/kokki) did not have any header. We added the Apache License and mentioned Kokki in the top level LICENSE. Let us know if there is an alternate way to handle this situation. We can incorporate it by next release. -Sumit On Thu, Jul 17, 2014 at 6:18 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, +1 binding - Vote passed - incubating in release name - signatures and hashes correct - DISCLAIMER exits - LICENSE and NOTICE good - No binary files in source release - all source files have correct headers - can compile from source I did notice one little odd thing and it's probably nothing, but just in case: In LICENSE you mention Kokki (BSD license) but all files under slider-agent/src/main/python/resource_management seem to have Apache headers. Should any files have BSD headers? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reviewing license / notice and bundled software
In the Bundling an AL Font thread on legal-discuss, sebb said: It is useful to mention all 3rd party inclusions in the LICENSE file, including ones under AL2.0: - Makes it much easier for the consumer to ensure that the code uses a license with which they are comfortable. - it helps the ASF project to ensure that all external inclusions are accounted for. Yes, it means updating the file every time an external version is updated, but the license still has to be checked in case it has changed. Not sure it can be mandated though. -Alex On 7/17/14 5:53 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Lets take for instance slider as they have just put up an RC for voting. Slider bundles a few things and may have some Apache Licensed software bundled. Can you tell easily what those bits are? And if so what versions? Source headers here are no help as all Apache source headers are the same. While no changes to LICENSE would be required for Apache bundled software, there may be missing items from the NOTICE file if you bundled software also has NOTICE files. BTW I don't think there is any issue with the RC in this case but it's hard to determine without a list of what has been bundled. Thanks, Justin - 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
