Re: [PROPOSAL]Pistachio
Hello Gavin, I would like to volunteer as mentor. I'm first time mentor, hope you will bare with me. Kytoto cabinet is under GNU GPL, but it is not a hard necessary dependency to Pistachio, it’s an optional pluggable storage engine. It’s designed in the way that it’s totally pluggable and very loosely coupled. We can easily remove it in graduation. I don't think removing dependency at graduation is option for incubator releases. You might have to remove it for the first incubating release itself. Thanks Amareshwari On Thu, Jun 25, 2015 at 9:36 PM, Gavin Li lyo.ga...@gmail.com wrote: We need more mentors. Please let me know if you are interested. THanks, Gavin Li On Mon, Jun 22, 2015 at 8:25 PM, Gavin Li lyo.ga...@gmail.com wrote: Roman, I think Pistachio is similar to Ignite in the sense that they both try to distribute the computation to storage to co-locate the data and computation. One difference might be Pistachio also supports other storage options like disk based storage to support longer term durability. Actually Pistachio was originally developed as a storage system of SSD disk and has been used on our large scale production serving system with SSD disk. We're not that familiar with Geode, I'll look into it and provide some detailed comparisons. Thanks, Gavin Li On Mon, Jun 22, 2015 at 8:00 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Jun 22, 2015 at 7:54 PM, Gavin Li lyo.ga...@gmail.com wrote: The other difference is in Pistachio we can do computation based on in-memory storage with data replication. Different from the in-memory computation in Spark, the storage can be in-memory here. Have you guys looked at in-memory computation layers offered by Ignite and Geode? I would love to know what you think about those. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Licensing Issue
Stefan, In order to open source something, you have to define what you mean by open source. If you mean that anybody can do anything at all with the code including claim it as their own, then you mean to put it into the public domain https://en.wikipedia.org/wiki/Public_domain. If you mean anything else at all, then you have to specify what you mean. Even if all you want to say is that people have to admit that you wrote the code, you have to specify that. The way that you specify what you want is to pick or write a license. On Thu, Jun 25, 2015 at 1:29 PM, Stefan Reich stefan.reich.maker.of@googlemail.com wrote: Please - can we all stop using licenses and just open source everything? Progress is waiting for us. BTW, I am now adding all (!) programming languages to the realm of AI. (Meaning they can then be programmed automatically.) tinybrain.blog.de Cheers Stefan Am 21.06.2015 00:51 schrieb Lewis John Mcgibbney lewis.mcgibb...@gmail.com: Hi Folks, I am looking for some advice here. We are currently in conversation about potentially transitioning the Joshua project [0] to the foundation. Our current conversation is ongoing at [1]. From one of the key developers of Joshua, the following question has arose; There is an issue with an LGPL'd library for handling language models (KenLM https://github.com/kpu/kenlm). There is an alternative (BerkeleyLM), but it is not actively maintained any more and is not quite as good as KenLM in a few key respects. A quick glance at the incubator page suggests that this dependency would keep the project from becoming a full-fledged one. Can you comment on this? Thanks for any input folks Lewis [0] http://joshua-decoder.org/ [1] https://github.com/joshua-decoder/joshua/issues/204 -- *Lewis*
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On 25.06.2015 09:17, Jochen Theodorou wrote: Am 24.06.2015 23:32, schrieb Ross Gardler (MS OPEN TECH): For HTTPd I was referring to the assertion from Justin earlier in this thread FWIW, httpd always had nightly tarballs available for consumption and testing. (though reading that now I wonder if he meant source tarballs - which is an easy way of resolving this whole issue) I don't see how that makes anything easier: it doesn't matter if the package contains source or binaries or pictures of kittens, the only question is whether it's a release or not. nightly source tarballs? Is that really a thing? Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and yet it can actually run on computers! :) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Atlas version 0.5-incubating
+1 (non-binding) Thanks Venkat On 6/24/15, 6:46 PM, Venkatesh Seetharam venkat...@apache.org wrote: Hello folks, This is a call for a vote on the Apache Atlas 0.5 incubating release. A vote was held on developer mailing list and it passed with 9 +1's. Vote thread: http://s.apache.org/RyM Results thread: http://s.apache.org/f8S The source tarball (*.tar.gz), signature (*.asc), checksum (*.md5, *.sha): https://dist.apache.org/repos/dist/dev/incubator/atlas/0.5.0-incubating-rc0 The commit id (318abdacd4c4d17a3d613c1cda04a58194042715) to ve voted upon: https://git-wip-us.apache.org/repos/asf?p=incubator-atlas.git;a=commit;h=318abdacd4c4d17a3d613c1cda04a58194042715 The tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=incubator-atlas.git;a=tag;h=refs/tags/release-0.5-rc0 The list of fixed issues: https://git-wip-us.apache.org/repos/asf?p=incubator-atlas.git;a=blob;f=release-log.txt;h=df92e95d408469b2bea5b988fb9be3de802b9f2b;hb=318abdacd4c4d17a3d613c1cda04a58194042715 Keys to verify the signature of the release artifact are available at: http://www.apache.org/dist/incubator/atlas/KEYS PGP release keys: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x1B16738C42C7A5EA Note that this is a source only release and we are voting on the source. Checksums: SHA1 (apache-atlas-0.5-incubating-sources.tar.gz = ab21ce037e488a8e5b8986353adb853dc515abd4) MD5 (apache-atlas-0.5-incubating-sources.tar.gz) = e358ed601233f7d00ba9eb1c64095f55 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks! Regards, Venkatesh - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP-CLEARANCE] CouchDB Docker
No -1s in 72 hours. This clearance passes. Thanks all! Jan -- On 20 Jun 2015, at 15:58, Jan Lehnardt j...@apache.org wrote: Heya, on behalf of the CouchDB project, I’d like to request IP Clearance for CouchDB Docker: https://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/couchdb-docker.xml?view=markup https://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/couchdb-docker.xml?view=markup Code: http://people.apache.org/~jan/docker-couchdb-master-c7f8b662.zip http://people.apache.org/~jan/docker-couchdb-master-c7f8b662.zip Origin: https://github.com/klaemo/docker-couchdb https://github.com/klaemo/docker-couchdb Community vote is positive, ICLAs are filed. Thank you! Jan -- - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [IP-CLEARANCE] CouchDB nano
No -1s in 72 hours. This clearance passes. Thanks all! Jan -- On 22 Jun 2015, at 12:32, Jan Lehnardt j...@apache.org wrote: Heya, on behalf of the CouchDB project, I’d like to request IP Clearance for CouchDB nano: https://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/couchdb-nano.xml?view=markup Code: https://dl.dropboxusercontent.com/u/1809262/nano-asf/nano.tar.gz Origin: https://github.com/dscape/nano Community vote is positive, ICLAs are filed. Thank you! Jan -- - 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: [IP-CLEARANCE] CouchDB CouchPerUser
No -1s in 72 hours. This clearance passes. Thanks all! Jan -- On 20 Jun 2015, at 16:02, Jan Lehnardt j...@apache.org wrote: Heya, on behalf of the CouchDB project, I’d like to request IP Clearance for CouchDB CouchPerUser: https://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/couchdb-couchperuser.xml?view=markup Code: https://people.apache.org/~klaus_trainer/dist/ip-clearance/ Origin: https://github.com/etrepum/couchperuser https://github.com/KlausTrainer/couchperuser Community vote is positive, ICLA is filed. Thank you! Jan -- - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Professional Support for Apache CouchDB: http://www.neighbourhood.ie/couchdb-support/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL]Pistachio
Thank you, Amareshwari. On Friday, June 26, 2015, Jake Farrell jfarr...@apache.org wrote: Hi Amareshwari Thanks for catching the incorrect wording for removing the dependency before graduation, should have been before first incubating release, updated. Glad to have you on board as a mentor Updated proposal is now available on the wiki at https://wiki.apache.org/incubator/PistachioProposal -Jake On Fri, Jun 26, 2015 at 2:21 AM, amareshwarisr . amareshw...@gmail.com javascript:; wrote: Hello Gavin, I would like to volunteer as mentor. I'm first time mentor, hope you will bare with me. Kytoto cabinet is under GNU GPL, but it is not a hard necessary dependency to Pistachio, it’s an optional pluggable storage engine. It’s designed in the way that it’s totally pluggable and very loosely coupled. We can easily remove it in graduation. I don't think removing dependency at graduation is option for incubator releases. You might have to remove it for the first incubating release itself. Thanks Amareshwari On Thu, Jun 25, 2015 at 9:36 PM, Gavin Li lyo.ga...@gmail.com javascript:; wrote: We need more mentors. Please let me know if you are interested. THanks, Gavin Li On Mon, Jun 22, 2015 at 8:25 PM, Gavin Li lyo.ga...@gmail.com javascript:; wrote: Roman, I think Pistachio is similar to Ignite in the sense that they both try to distribute the computation to storage to co-locate the data and computation. One difference might be Pistachio also supports other storage options like disk based storage to support longer term durability. Actually Pistachio was originally developed as a storage system of SSD disk and has been used on our large scale production serving system with SSD disk. We're not that familiar with Geode, I'll look into it and provide some detailed comparisons. Thanks, Gavin Li On Mon, Jun 22, 2015 at 8:00 PM, Roman Shaposhnik ro...@shaposhnik.org javascript:; wrote: On Mon, Jun 22, 2015 at 7:54 PM, Gavin Li lyo.ga...@gmail.com javascript:; wrote: The other difference is in Pistachio we can do computation based on in-memory storage with data replication. Different from the in-memory computation in Spark, the storage can be in-memory here. Have you guys looked at in-memory computation layers offered by Ignite and Geode? I would love to know what you think about those. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:;
Re: [PROPOSAL]Pistachio
Thanks Gavin. Please let me suggest that novelty is not a requirement for incubation, and a proposal doesn't need to make claims of novelty to be accepted. Should the proposal be accepted for incubation, you may find your new neighbors at Apache can do X where you weren't aware of it. It will be totally up to the new podling if you want to survey the landscape when figuring out how to differentiate, but I do recommend it, it may help you crystallize a community around a real difference and advantage provided by Pistachio. On Mon, Jun 22, 2015 at 7:54 PM, Gavin Li lyo.ga...@gmail.com wrote: Hi Andrew, As we described more in http://yahooeng.tumblr.com/post/116291838351/pistachio-co-locate-the-data-and-compute-for , a very common problem we saw in Hadoop use cases is we often need to persist the previous result of one map reduce job onto HDFS, then the next day we process the new data together with the previous result. Usually the most expensive part is the shuffling part where we need to join the previous data and the new data together. It's so expensive because HDFS doesn't store the data in a partitioned way. So data have to be transferred again and again in the shuffling phase. Instead, in Pistachio we do the computation right on top of the partitioned storage layer, so that the previous result is always stored in a partitioned way, so shuffling can be avoided. Expensive IO and roundtrips can thus be avoided so that much better performance can be achieved. The other difference is in Pistachio we can do computation based on in-memory storage with data replication. Different from the in-memory computation in Spark, the storage can be in-memory here. Please let me know if I'm not clear enough. Thanks, Gavin Li On Mon, Jun 22, 2015 at 7:53 PM, Andrew Purtell apurt...@apache.org wrote: It was a simple question, and not meant to suggest anything one way or other regarding my opinion of this proposal. On Monday, June 22, 2015, John D. Ament johndam...@apache.org wrote: On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell apurt...@apache.org javascript:; wrote: Pistachio can easily embed computation to the storage layer to achieve the best data locality to improve the computation performance significantly which is an innovative model comparing with the normal ways where the storage and compute are independent to each other. Have you heard of something called Hadoop? Regardless of whether he has or not - what's your point? The ASF has historically not denied the entry of new projects just because their domain intersects with another project's. On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li lyo.ga...@gmail.com javascript:; wrote: Hi, I want to propose project Pistachio to enter Apache Incubator. Below please find the proposal. Thanks, Gavin Li = Pistachio = == Abstract == Pistachio is a fault-tolerant low latency distributed storage system which enables simple embedding the computation to the storage layer to achieve best data locality. It evolves from Yahoo’s global user profile storage system. == Proposal == Pistachio is a distributed key value store system with fault tolerance and consistency guarantee. It supports multiple local storage engine including in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the user profile storage for massive scale global ads products in Yahoo storing 10+ billion user profiles. The performance and reliability has been well proven on production. Pistachio can easily embed computation to the storage layer to achieve the best data locality to improve the computation performance significantly which is an innovative model comparing with the normal ways where the storage and compute are independent to each other. == Background == Pistachio is originally designed and optimized for Yahoo’s large scale global open RTB(real-time bidding) use cases where latency is critical(the whole request needs to be finished within 100ms including network round trips). It stores 10+ billion user profiles in 8 data centers. Then because of the great performance and the flexibility of local storage choices, we evolved it to do distributed compute. Rich call back interfaces are added to supports easy compute directly on top of the storage system local to the data partition. This model is totally different from the traditional distributed computation model where the storage and compute are separated and independent. In the new model we found data locality can be improved significantly and lots of data access round trips can be reduced in
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Am 26.06.2015 11:39, schrieb Jochen Theodorou: Am 26.06.2015 09:19, schrieb Branko Čibej: On 25.06.2015 09:17, Jochen Theodorou wrote: [...] nightly source tarballs? Is that really a thing? Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and yet it can actually run on computers! :) I was asking because whoever is able to setup an environment to build httpd is surely also able to use the repository directly to get exactly the version they want... in the Java world it can be more easy thanks to Ivy, gradle and maven and you can go with almost no setup I want to add, that it looks like httpd is a bad example for nightly builds, since (unless I am wrong) it seems there has been no activity in repository that I could call by anything daily recently. So if they should have nightly builds, I doubt their use. bye blackdrag -- Jochen blackdrag Theodorou blog: http://blackdragsview.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Licensing Issue
On Fri, Jun 26, 2015 at 6:58 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Oddly, you as an individual in the US can't *put* a work into the public domain, but you can make a quit claim that forswears defense of any of the exclusive rights of you, the copyright holder. That does not in any way remove the copyright that the work was born having, however. Wow. Just did some research on this and Dennis (not surprisingly) appears to be right. Yay for the Creative Commons licenses in this case. The CC0 license looks very useful. But either way, one cannot assert any kind of property right over a work that is not yours (or of someone providing work for hire to you), whether public domain or not. Perhaps true in a literal sense. Nearly trivial (nearly!) derivative works can be claimed with no attribution, I think if a license like the CC0 has been applied. The issue of moral rights, especially in Europe, seems sticky.
RE: Licensing Issue
Small but important correction. It is not permissible to claim a public-domain creation of another as your own. There is no open-range, mustang copyright arrangement. In the US, works of the US Government are born public-domain. Not others. Oddly, you as an individual in the US can't *put* a work into the public domain, but you can make a quit claim that forswears defense of any of the exclusive rights of you, the copyright holder. That does not in any way remove the copyright that the work was born having, however. But either way, one cannot assert any kind of property right over a work that is not yours (or of someone providing work for hire to you), whether public domain or not. -Original Message- From: Ted Dunning [mailto:ted.dunn...@gmail.com] Sent: Thursday, June 25, 2015 23:51 To: general@incubator.apache.org Subject: Re: Licensing Issue Stefan, In order to open source something, you have to define what you mean by open source. If you mean that anybody can do anything at all with the code including claim it as their own, then you mean to put it into the public domain https://en.wikipedia.org/wiki/Public_domain. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Am 26.06.2015 09:19, schrieb Branko Čibej: On 25.06.2015 09:17, Jochen Theodorou wrote: [...] nightly source tarballs? Is that really a thing? Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and yet it can actually run on computers! :) I was asking because whoever is able to setup an environment to build httpd is surely also able to use the repository directly to get exactly the version they want... in the Java world it can be more easy thanks to Ivy, gradle and maven and you can go with almost no setup bye blackdrag -- Jochen blackdrag Theodorou blog: http://blackdragsview.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Licensing Issue
There's a difference between making a claim, affixing a notice, etc., and it being lawful and the right to having done so being legally defensible. I suspect this normally doesn't matter and is a trifle unless a conflict of some sort drags the usurper into court. Finding plagiarism, even in a derivative, will be quite unfortunate. - Dennis orcnote / below. -Original Message- From: Ted Dunning [mailto:ted.dunn...@gmail.com] Sent: Friday, June 26, 2015 18:18 To: general@incubator.apache.org; Dennis Hamilton Subject: Re: Licensing Issue On Fri, Jun 26, 2015 at 6:58 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: [ ... ] But either way, one cannot assert any kind of property right over a work that is not yours (or of someone providing work for hire to you), whether public domain or not. Perhaps true in a literal sense. Nearly trivial (nearly!) derivative works can be claimed with no attribution, I think if a license like the CC0 has been applied. The issue of moral rights, especially in Europe, seems sticky. orcnote If the creation of the derivative work is allowed, the claim by the creator of the derivative extends only to the aspects that are original with that creator. I think it is basically the case that one does not gain copyright over work that is not one's own (or obtained by hiring someone) by any means unless there has been a [recorded] copyright transfer (a license not being enough). [This might be a (probably-minor) component in how the Oracle v. Google appeal is resolved by SCOTUS.)] /orcnote - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Atlas version 0.5-incubating
+1 (non binding) We have been running regressions tests on this release and dont see any blockers. -- Arpit Gupta Hortonworks Inc. http://hortonworks.com/ On Jun 25, 2015, at 12:25 PM, Jakob Homan jgho...@gmail.com wrote: +1 (binding, forwarded from podling vote) On 25 June 2015 at 10:05, Jon Maron jma...@hortonworks.com wrote: +1 On Jun 24, 2015, at 9:46 PM, Venkatesh Seetharam venkat...@apache.org wrote: Hello folks, This is a call for a vote on the Apache Atlas 0.5 incubating release. A vote was held on developer mailing list and it passed with 9 +1's. Vote thread: http://s.apache.org/RyM Results thread: http://s.apache.org/f8S The source tarball (*.tar.gz), signature (*.asc), checksum (*.md5, *.sha): https://dist.apache.org/repos/dist/dev/incubator/atlas/0.5.0-incubating-rc0 The commit id (318abdacd4c4d17a3d613c1cda04a58194042715) to ve voted upon: https://git-wip-us.apache.org/repos/asf?p=incubator-atlas.git;a=commit;h=318abdacd4c4d17a3d613c1cda04a58194042715 The tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=incubator-atlas.git;a=tag;h=refs/tags/release-0.5-rc0 The list of fixed issues: https://git-wip-us.apache.org/repos/asf?p=incubator-atlas.git;a=blob;f=release-log.txt;h=df92e95d408469b2bea5b988fb9be3de802b9f2b;hb=318abdacd4c4d17a3d613c1cda04a58194042715 Keys to verify the signature of the release artifact are available at: http://www.apache.org/dist/incubator/atlas/KEYS PGP release keys: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x1B16738C42C7A5EA Note that this is a source only release and we are voting on the source. Checksums: SHA1 (apache-atlas-0.5-incubating-sources.tar.gz = ab21ce037e488a8e5b8986353adb853dc515abd4) MD5 (apache-atlas-0.5-incubating-sources.tar.gz) = e358ed601233f7d00ba9eb1c64095f55 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks! Regards, Venkatesh - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
