Re: [PROPOSAL] Gora to enter Incubator
+1 (not binding) Tommaso 2010/9/13 Mohammad Nour El-Din nour.moham...@gmail.com +1 (Not binding) On Mon, Sep 13, 2010 at 4:46 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: My +1 to this proposal, but we certainly need at least one more mentor, please, if you’re interested sign up. Thanks! Cheers, Chris On 9/13/10 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users.
Re: [PROPOSAL] Gora to enter Incubator
This is how a person like me perceives the project. ORM... Mmm... The acronym resembles CRM. Aha, this is CRM for stores which sell these colum things! :-) P.S. I've got the point. Later. On Tue, Sep 14, 2010 at 11:33 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: +1 (not binding) Tommaso 2010/9/13 Mohammad Nour El-Din nour.moham...@gmail.com +1 (Not binding) On Mon, Sep 13, 2010 at 4:46 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: My +1 to this proposal, but we certainly need at least one more mentor, please, if you’re interested sign up. Thanks! Cheers, Chris On 9/13/10 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial
Re: [PROPOSAL] Gora to enter Incubator
Very cool. Note this can also be used for B+Tree NoSQL databases that are not distributed as well like JDBM. +1 Regards, Alex On Mon, Sep 13, 2010 at 4:10 PM, Enis Soztutar enis.soz.nu...@gmail.comwrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the project out of Nutch. Later Julien Nioche, Andrzej Bialecki and Doğacan has ported Nutch to use the newly formed project. Later, Sertan Alkan has joined. Doğacan
Re: Not receiving any email from *...@*.apache.org
Start by mailing infrastruct...@a.o, and ask there. Alternatively you can try asking on IRC on #asfinfra on freenode. Upayavira On Mon, 2010-09-13 at 15:59 -0400, George Aroush wrote: Hi Everyone, Sorry about the spam. Since Sept 12, 2010, I have not received any email from all of my Apache subscriptions such as *...@lucene.apache.org, or *...@incubator.apache.org or *...@apache.org and I have several of them which Im subscribed to (all of Solrs mailing list, all of Lucene, all of Lucene.Net, private and general). Not only that, my post to them is not working either. My 2 email replies to Grants email on priv...@lucene.apache.org did not show up. My post to lucene-net-...@lucene.apache.org did not show up!! If you do get this email, please reply to my email as well: geo...@aroush.net (since I may not see it in my in-box) and let me know if there is any issues with Apaches email server or something is wrong on my end!! Thanks, -- George - 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] ALOIS to enter the incubator
[X] +1, bring ALOIS into Incubator On Mon, Sep 13, 2010 at 5:33 PM, Urs Lerch m...@ulerch.net wrote: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some revision. It is a given goal of the project to allow modules in other programming language. Furthermore, it has been discussed if parts of the existing implementation may be replaced with other proven open source software,
Re: Accepting patches in a podling
On Tue, Sep 14, 2010 at 2:58 AM, Benson Margulies bimargul...@gmail.com wrote: All patches should be attached to JIRAs with the 'grant' checkbox checked. Only if they are large do you then have to contemplate asking for a CLA and going through the clearance process. Or so I understand it. Sounds good, and as it's about podlings I'd add and make those folks committers rather sooner than later. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] ALOIS to enter the incubator
[X] +1, bring ALOIS into Incubator On Tue, Sep 14, 2010 at 1:56 AM, Christian Grobmeier grobme...@gmail.comwrote: [X] +1, bring ALOIS into Incubator On Mon, Sep 13, 2010 at 5:33 PM, Urs Lerch m...@ulerch.net wrote: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some
Re: [VOTE] ALOIS to enter the incubator
I might be missing it, but is there a link to the existing GPL project/code? Thanks --tim On Mon, Sep 13, 2010 at 11:33 AM, Urs Lerch m...@ulerch.net wrote: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some revision. It is a given goal of the project to allow modules in other programming language. Furthermore, it has been discussed if parts of the existing implementation
Re: [VOTE] ALOIS to enter the incubator
Hi Tim Unfortunately, so far there is no link to the existing code. Until now the software has been used only in two organizations. Be asured that we are aware that we have to do a lot of basic work to release the code to the community. Nontheless, if you are interested I can send you the code as it is. Best Urs Am Dienstag, den 14.09.2010, 07:54 -0400 schrieb Tim Williams: I might be missing it, but is there a link to the existing GPL project/code? Thanks --tim On Mon, Sep 13, 2010 at 11:33 AM, Urs Lerch m...@ulerch.net wrote: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large
[VOTE] Apache Chemistry OpenCMIS 0.1.0-incubating (RC2)
Dear Incubator PMC members, on behalf of the Chemistry dev team, I'd like to ask your approval to release the RC2 packages as Chemistry OpenCMIS 0.1.0-incubating. Legal and packaging issues - that blocked RC1- should have been now resolved (https://issues.apache.org/jira/browse/CMIS-224), while detailed release notes can be found in Jira at: https://issues.apache.org/jira/browse/CMIS/fixforversion/12315133 . The release has passed the Chemistry incubator PMC vote: http://mail-archives.apache.org/mod_mbox/incubator-chemistry-dev/201009.mbox/%3cf6d8594e-4913-4af6-aaab-a1b30e951...@apache.org%3e . During the vote, also 2 IPMC (Nick Burch Jukka Zitting) votes have been collected, so we'd need one more IPMC +1 to proceed with the release. Main release candidate packages (for distribution at apache.org/dist) are at: http://people.apache.org/~gabriele/chemistry/opencmis/0.1.0-incubating-rc2/dist/ The full set of Maven artifacts (for distribution at repository.apache.org) is at: https://repository.apache.org/content/repositories/orgapachechemistry-012/ Sources tag can be found at: http://svn.apache.org/repos/asf/incubator/chemistry/opencmis/tags/chemistry-opencmis-0.1.0-incubating-RC2/ The staging maven documentation site is at : http://people.apache.org/~gabriele/chemistry/opencmis/0.1.0-incubating-rc2/site/ (full integration tests at: http://bit.ly/b07hK8) Artifacts have been signed using key D0383AE5 (publicly available at http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0xB0E9DD9ED0383AE5 and under http://svn.apache.org/repos/asf/incubator/chemistry/opencmis/trunk/KEYS) . The vote is open for 72 hours. Please cast your votes! [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks in advance! Gabriele -- Gabriele Columbro Alfresco Software, Ltd. http://www.mindthegab.com http://twitter.com/mindthegabz Keyboard not found. Press F1 to continue. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Fwd: Help with SVN access to River
More Infra-Capable incubator PMC members, help? -- Forwarded message -- From: Patricia Shanahan p...@acm.org Date: Tue, Sep 14, 2010 at 9:30 AM Subject: Re: Help with SVN access to River To: Benson Margulies bimargul...@gmail.com Here's an example. Maybe there is something else wrong with the command? bash-3.2$ svn copy https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManager-m 'Create work area for TaskManager experiments' --username pats Authentication realm: https://svn.apache.org:443 ASF Committers Password for 'pats': svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/repos/asf/!svn/ver/996690/incubator/river/jtsk/skunk' bash-3.2$ I get different results if I use a bad user name or password, so it is recognizing my account. Patricia On 9/14/2010 4:04 AM, Benson Margulies wrote: Did you switch to an https URL? On Tue, Sep 14, 2010 at 12:20 AM, Patricia Shanahanp...@acm.org wrote: Can you advise how to go about getting actual SVN committer access to River? The SVN server recognizes my user name and password, but does not let me e.g. create a new branch by svn copy. Thanks, Patricia
Re: Help with SVN access to River
The login pats has not been granted access to the incubator/river SVN tree This requires someone (normally the PMC chair, because they should know if the request is valid) to update the asf-authorization-template file. See: http://www.apache.org/dev/pmc.html#SVNaccess On 14 September 2010 14:48, Benson Margulies bimargul...@gmail.com wrote: More Infra-Capable incubator PMC members, help? -- Forwarded message -- From: Patricia Shanahan p...@acm.org Date: Tue, Sep 14, 2010 at 9:30 AM Subject: Re: Help with SVN access to River To: Benson Margulies bimargul...@gmail.com Here's an example. Maybe there is something else wrong with the command? bash-3.2$ svn copy https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManager-m 'Create work area for TaskManager experiments' --username pats Authentication realm: https://svn.apache.org:443 ASF Committers Password for 'pats': svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/repos/asf/!svn/ver/996690/incubator/river/jtsk/skunk' bash-3.2$ I get different results if I use a bad user name or password, so it is recognizing my account. Patricia On 9/14/2010 4:04 AM, Benson Margulies wrote: Did you switch to an https URL? On Tue, Sep 14, 2010 at 12:20 AM, Patricia Shanahanp...@acm.org wrote: Can you advise how to go about getting actual SVN committer access to River? The SVN server recognizes my user name and password, but does not let me e.g. create a new branch by svn copy. Thanks, Patricia - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help with SVN access to River
I sent what I thought was the usual request, or so I thought. oops. Help? On Tue, Sep 14, 2010 at 10:13 AM, sebb seb...@gmail.com wrote: The login pats has not been granted access to the incubator/river SVN tree This requires someone (normally the PMC chair, because they should know if the request is valid) to update the asf-authorization-template file. See: http://www.apache.org/dev/pmc.html#SVNaccess On 14 September 2010 14:48, Benson Margulies bimargul...@gmail.com wrote: More Infra-Capable incubator PMC members, help? -- Forwarded message -- From: Patricia Shanahan p...@acm.org Date: Tue, Sep 14, 2010 at 9:30 AM Subject: Re: Help with SVN access to River To: Benson Margulies bimargul...@gmail.com Here's an example. Maybe there is something else wrong with the command? bash-3.2$ svn copy https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManager-m 'Create work area for TaskManager experiments' --username pats Authentication realm: https://svn.apache.org:443 ASF Committers Password for 'pats': svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/repos/asf/!svn/ver/996690/incubator/river/jtsk/skunk' bash-3.2$ I get different results if I use a bad user name or password, so it is recognizing my account. Patricia On 9/14/2010 4:04 AM, Benson Margulies wrote: Did you switch to an https URL? On Tue, Sep 14, 2010 at 12:20 AM, Patricia Shanahanp...@acm.org wrote: Can you advise how to go about getting actual SVN committer access to River? The SVN server recognizes my user name and password, but does not let me e.g. create a new branch by svn copy. Thanks, Patricia - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help with SVN access to River
On 14 September 2010 15:13, sebb seb...@gmail.com wrote: The login pats has not been granted access to the incubator/river SVN tree This requires someone (normally the PMC chair, because they should know if the request is valid) to update the asf-authorization-template file. See: http://www.apache.org/dev/pmc.html#SVNaccess Also: http://incubator.apache.org/guides/mentor.html#who-auth-karma On 14 September 2010 14:48, Benson Margulies bimargul...@gmail.com wrote: More Infra-Capable incubator PMC members, help? -- Forwarded message -- From: Patricia Shanahan p...@acm.org Date: Tue, Sep 14, 2010 at 9:30 AM Subject: Re: Help with SVN access to River To: Benson Margulies bimargul...@gmail.com Here's an example. Maybe there is something else wrong with the command? bash-3.2$ svn copy https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManager-m 'Create work area for TaskManager experiments' --username pats Authentication realm: https://svn.apache.org:443 ASF Committers Password for 'pats': svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/repos/asf/!svn/ver/996690/incubator/river/jtsk/skunk' bash-3.2$ I get different results if I use a bad user name or password, so it is recognizing my account. Patricia On 9/14/2010 4:04 AM, Benson Margulies wrote: Did you switch to an https URL? On Tue, Sep 14, 2010 at 12:20 AM, Patricia Shanahanp...@acm.org wrote: Can you advise how to go about getting actual SVN committer access to River? The SVN server recognizes my user name and password, but does not let me e.g. create a new branch by svn copy. Thanks, Patricia - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Not receiving any email from *...@*.apache.org
Thanks to everyone who helped regarding this matter. I contacted my ISP and they told me they were blocking 148.211.11.3. They said it's unblocked now, so I'm testing to see if this was the case. Lets see if this email to general@incubator.apache.org will show up in my in-box. -- George On Mon, 2010-09-13 at 15:59 -0400, George Aroush wrote: Hi Everyone, Sorry about the spam. Since Sept 12, 2010, I have not received any email from all of my Apache subscriptions such as *...@lucene.apache.org, or *...@incubator.apache.org or *...@apache.org and I have several of them which I#146;m subscribed to (all of Solr#146;s mailing list, all of Lucene, all of Lucene.Net, private and general). Not only that, my post to them is not working either. My 2 email replies to Grant#146;s email on priv...@lucene.apache.org did not show up.My post to lucene-net-...@lucene.apache.org did not show up!! If you do get this email, please reply to my email as well: geo...@aroush.net (since I may not see it in my in-box) and let me know if there is any issues with Apache#146;s email server or something is wrong on my end!! Thanks, -- George - 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: Not receiving any email from *...@*.apache.org
ping :) On Tue, Sep 14, 2010 at 5:55 PM, George Aroush geo...@aroush.net wrote: Thanks to everyone who helped regarding this matter. I contacted my ISP and they told me they were blocking 148.211.11.3. They said it's unblocked now, so I'm testing to see if this was the case. Lets see if this email to general@incubator.apache.org will show up in my in-box. -- George On Mon, 2010-09-13 at 15:59 -0400, George Aroush wrote: Hi Everyone, Sorry about the spam. Since Sept 12, 2010, I have not received any email from all of my Apache subscriptions such as *...@lucene.apache.org, or �...@incubator.apache.org or *...@apache.org and I have several of them which I#146;m subscribed to (all of Solr#146;s mailing list, all of Lucene, all of Lucene.Net, private and general). Not only that, my post to them is not working either. My 2 email replies to Grant#146;s email on priv...@lucene.apache.org did not show up. My post to lucene-net-...@lucene.apache.org did not show up!! If you do get this email, please reply to my email as well: geo...@aroush.net (since I may not see it in my in-box) and let me know if there is any issues with Apache#146;s email server or something is wrong on my end!! Thanks, -- George - 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Gora to enter Incubator
+1 Sounds like a great project. Doug On 09/13/2010 06:10 AM, Enis Soztutar wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the project out of Nutch. Later Julien Nioche, Andrzej Bialecki and Doğacan has ported Nutch to use the newly formed project. Later, Sertan Alkan has joined. Doğacan and Julien are Nutch PMC members, Andrzej is the Nutch PMC chair. Enis is an Apache Hadoop PMC member. === Alignment === As discusssed in the second paragraph of Rationale Section, all of the
Re: [PROPOSAL] Gora to enter Incubator
+1 (not binding) This really strikes a chord with me and I would love to help out with this project in any way that I can. I'm a committer on the incubating OODT project and have experience with a variety of the traditional ORM's, developing web interfaces, and data modeling. -Andrew. On 9/14/10 9:47 AM, Doug Cutting wrote: +1 Sounds like a great project. Doug On 09/13/2010 06:10 AM, Enis Soztutar wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the
Re: [PROPOSAL] Gora to enter Incubator
Hey Andrew, Great! Please add yourself to the wiki page as a commuter and we'd love a helping hand! Cheers, Chris Sent from my iPad On Sep 14, 2010, at 9:59 AM, Andrew Hart ah...@apache.org wrote: +1 (not binding) This really strikes a chord with me and I would love to help out with this project in any way that I can. I'm a committer on the incubating OODT project and have experience with a variety of the traditional ORM's, developing web interfaces, and data modeling. -Andrew. On 9/14/10 9:47 AM, Doug Cutting wrote: +1 Sounds like a great project. Doug On 09/13/2010 06:10 AM, Enis Soztutar wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to
Re: [PROPOSAL] Gora to enter Incubator
Lol s/commuter/committer Sent from my iPad On Sep 14, 2010, at 10:22 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Andrew, Great! Please add yourself to the wiki page as a commuter and we'd love a helping hand! Cheers, Chris Sent from my iPad On Sep 14, 2010, at 9:59 AM, Andrew Hart ah...@apache.org wrote: +1 (not binding) This really strikes a chord with me and I would love to help out with this project in any way that I can. I'm a committer on the incubating OODT project and have experience with a variety of the traditional ORM's, developing web interfaces, and data modeling. -Andrew. On 9/14/10 9:47 AM, Doug Cutting wrote: +1 Sounds like a great project. Doug On 09/13/2010 06:10 AM, Enis Soztutar wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial
Re: [PROPOSAL] Gora to enter Incubator
Does he have to be a commuter? Perhaps it's a non-abelian project? On Tue, Sep 14, 2010 at 1:20 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Andrew, Great! Please add yourself to the wiki page as a commuter and we'd love a helping hand! Cheers, Chris Sent from my iPad On Sep 14, 2010, at 9:59 AM, Andrew Hart ah...@apache.org wrote: +1 (not binding) This really strikes a chord with me and I would love to help out with this project in any way that I can. I'm a committer on the incubating OODT project and have experience with a variety of the traditional ORM's, developing web interfaces, and data modeling. -Andrew. On 9/14/10 9:47 AM, Doug Cutting wrote: +1 Sounds like a great project. Doug On 09/13/2010 06:10 AM, Enis Soztutar wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community
Re: [PROPOSAL] Gora to enter Incubator
+1 (non-binding) very interesting project. I would definitely love to help on this project any way I can. - Henry On Mon, Sep 13, 2010 at 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.comwrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the project out of Nutch. Later Julien Nioche, Andrzej Bialecki and Doğacan has ported Nutch to use the newly formed project. Later, Sertan Alkan has joined. Doğacan and
Re: No dev-, user- lists for small podlings (was: Re: [PROPOSAL] Kitty to Enter the Incubator)
On 9/10/2010 11:25 PM, Justin Erenkrantz wrote: On Thu, Sep 9, 2010 at 12:20 PM, Greg Stein gst...@gmail.com wrote: For reference: * Subversion created its dev list in April 2000. * The user list was created in July 2003. 238 messages were posted that month. As you can see, we waited a very long time before sending users to their own list. Our dev list was very heavily trafficked by our users. It kept the larger community together until the point where they could safely work on their own. I think my post at the time gives light as to why we waited so long and why I felt it was time for the user list to be created: http://svn.haxx.se/dev/archive-2003-07/1363.shtml BTW, those 238 messages in July all came in 10 days... =P -- justin Training users to actually move to the users@ list in 10 days in and of itself is pretty amazing :) Agreed that this is not appropriate for the typical incubator project, both my own mod_aspdotnet podling and those such as stdcxx or lokahi would have done better on just one [public] list. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Gora to enter Incubator
+1 non-binding. As someone who has wrestled with this before, sounds like a worthwhile abstraction layer... I'm happy to help. -Dave On Sep 13, 2010, at 6:10 AM, Enis Soztutar wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the project out of Nutch. Later Julien Nioche, Andrzej Bialecki and Doğacan has ported Nutch to use the newly formed project. Later, Sertan Alkan has joined. Doğacan and Julien are
Re: [PROPOSAL] Gora to enter Incubator
Hi Folks, FYI, if any mentors out there have free cycles and are interested, we are looking for 1 more mentor to fulfill the Incubator mentor requirements. Thanks, Chris On 9/13/10 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the project out of Nutch. Later Julien Nioche, Andrzej Bialecki and Doğacan has ported Nutch to use the newly formed project. Later, Sertan Alkan has joined. Doğacan and Julien are Nutch PMC members, Andrzej is the Nutch
Re: [PROPOSAL] Gora to enter Incubator
Hi, On Tue, Sep 14, 2010 at 11:44 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: FYI, if any mentors out there have free cycles and are interested, we are looking for 1 more mentor to fulfill the Incubator mentor requirements. I'm interested to mentor, but I would be a newbie. And as Andrzej Bialecki is also new in that role I guess you are looking for a more experienced mentor? Kind Regards, Stefan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Not receiving any email from *...@*.apache.org
George Aroush wrote on Tue, Sep 14, 2010 at 11:55:28 -0400: Thanks to everyone who helped regarding this matter. I contacted my ISP and they told me they were blocking 148.211.11.3. Presumably you meant s/148/140/? They said it's unblocked now, so I'm testing to see if this was the case. Lets see if this email to general@incubator.apache.org will show up in my in-box. -- George On Mon, 2010-09-13 at 15:59 -0400, George Aroush wrote: Hi Everyone, Sorry about the spam. Since Sept 12, 2010, I have not received any email from all of my Apache subscriptions such as *...@lucene.apache.org, or *...@incubator.apache.org or *...@apache.org and I have several of them which I#146;m subscribed to (all of Solr#146;s mailing list, all of Lucene, all of Lucene.Net, private and general). Not only that, my post to them is not working either. My 2 email replies to Grant#146;s email on priv...@lucene.apache.org did not show up.My post to lucene-net-...@lucene.apache.org did not show up!! If you do get this email, please reply to my email as well: geo...@aroush.net (since I may not see it in my in-box) and let me know if there is any issues with Apache#146;s email server or something is wrong on my end!! Thanks, -- George - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Gora to enter Incubator
I posted a little earlier volunteering to be a mentor, but it looks like it may be in the moderation queue. Anyway, +1 to the proposal, and happy to help out if you still need a mentor. Cheers, Tom On Tue, Sep 14, 2010 at 2:44 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, FYI, if any mentors out there have free cycles and are interested, we are looking for 1 more mentor to fulfill the Incubator mentor requirements. Thanks, Chris On 9/13/10 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more
Re: [PROPOSAL] Gora to enter Incubator
Thanks Tom. If you don’t beat me to it, I’ll add you to the Gora proposal on the Wiki in a few hours. Thanks! Cheers, Chris On 9/14/10 3:16 PM, Tom White tom.e.wh...@gmail.com wrote: I posted a little earlier volunteering to be a mentor, but it looks like it may be in the moderation queue. Anyway, +1 to the proposal, and happy to help out if you still need a mentor. Cheers, Tom On Tue, Sep 14, 2010 at 2:44 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, FYI, if any mentors out there have free cycles and are interested, we are looking for 1 more mentor to fulfill the Incubator mentor requirements. Thanks, Chris On 9/13/10 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been
Re: [PROPOSAL] Gora to enter Incubator
Hi Stefan, Any mentor is very welcome! Please, join up! Cheers, Chris On 9/14/10 3:03 PM, Stefan Seelmann seelm...@apache.org wrote: Hi, On Tue, Sep 14, 2010 at 11:44 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: FYI, if any mentors out there have free cycles and are interested, we are looking for 1 more mentor to fulfill the Incubator mentor requirements. I'm interested to mentor, but I would be a newbie. And as Andrzej Bialecki is also new in that role I guess you are looking for a more experienced mentor? Kind Regards, Stefan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: [PROPOSAL] Gora to enter Incubator
+1 Sounds very interesting. I'd be happy to help out as a mentor. Cheers, Tom On Mon, Sep 13, 2010 at 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch community for a while. If Gora is accepted to Apache Incubator, we expect more traction. Moreover, with the increasing popularity of NoSQL databases, we expect more users. === Core Developers === Gora was started by the initial code base inside Apache Nutch by Doğacan Güney. Then Enis Söztutar has refactored and re-architected the project out of Nutch. Later Julien Nioche, Andrzej Bialecki and Doğacan has ported Nutch to use the newly formed project. Later, Sertan Alkan has joined. Doğacan and Julien are Nutch PMC members, Andrzej is the
Re: [VOTE] Kitty to Enter the Incubator (was PROPOSAL)
Changing subject to VOTE On Sep 8, 2010, at 11:29 PM, Pid wrote: On 09/09/2010 07:15, Greg Stein wrote: Just to clarify: I'm assuming you're saying +1 to the proposal, rather than to my comment. Correct? +1 indeed, to the proposal +1 actually, to the mailing list comment, too. The Incubator PMC might consider that establishing sufficient interest which requires a user list is an indicator of a project approaching the exit criteria, or at least, making substantial progress. p And to clarify for myself: I have no opinion on the proposal itself. I timed out after Java and the next few buzzwords. Thankfully, this proposal didn't say framework or I may have timed out after the first :-P ... my comments were focused on the community aspects around mailing list management, and successfully growing a lively and sustainable critical mass. Cheers, -g On Thu, Sep 9, 2010 at 02:06, Pid p...@pidster.com wrote: +1 (non-binding) Small point: if a Mentor must be a Member, I can't be one, because I'm not. p On 08/09/2010 16:00, Mohammad Nour El-Din wrote: +1 (Notbinding) On Wed, Sep 8, 2010 at 7:22 AM, Greg Stein gst...@gmail.com wrote: On Tue, Sep 7, 2010 at 20:29, Matthew Sacks matt...@matthewsacks.comwrote: ... *Mailing Lists* kitty-dev kitty-commits kitty-user Is there a large user community already? If not, then splitting the community across dev/user does not make sense. You want to keep the users and developers on the same mailing list until one starts to overwhelm the other. By partitioning the lists too early, you risk never reaching critical mass on *either* mailing list. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 0x62590808.asc - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Kitty to Enter the Incubator (was PROPOSAL)
+1 On Wed, Sep 15, 2010 at 6:57 AM, Matthew Sacks matt...@matthewsacks.com wrote: Changing subject to VOTE On Sep 8, 2010, at 11:29 PM, Pid wrote: On 09/09/2010 07:15, Greg Stein wrote: Just to clarify: I'm assuming you're saying +1 to the proposal, rather than to my comment. Correct? +1 indeed, to the proposal +1 actually, to the mailing list comment, too. The Incubator PMC might consider that establishing sufficient interest which requires a user list is an indicator of a project approaching the exit criteria, or at least, making substantial progress. p And to clarify for myself: I have no opinion on the proposal itself. I timed out after Java and the next few buzzwords. Thankfully, this proposal didn't say framework or I may have timed out after the first :-P ... my comments were focused on the community aspects around mailing list management, and successfully growing a lively and sustainable critical mass. Cheers, -g On Thu, Sep 9, 2010 at 02:06, Pid p...@pidster.com wrote: +1 (non-binding) Small point: if a Mentor must be a Member, I can't be one, because I'm not. p On 08/09/2010 16:00, Mohammad Nour El-Din wrote: +1 (Notbinding) On Wed, Sep 8, 2010 at 7:22 AM, Greg Stein gst...@gmail.com wrote: On Tue, Sep 7, 2010 at 20:29, Matthew Sacks matt...@matthewsacks.comwrote: ... *Mailing Lists* kitty-dev kitty-commits kitty-user Is there a large user community already? If not, then splitting the community across dev/user does not make sense. You want to keep the users and developers on the same mailing list until one starts to overwhelm the other. By partitioning the lists too early, you risk never reaching critical mass on *either* mailing list. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 0x62590808.asc - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Kitty to Enter the Incubator (was PROPOSAL)
No hurry. Please, do us all favor and start a new thread for a vote, unless you really don't want to receive any votes. I can't find the proposal on the wiki either. Many thanks, Bernd On Wed, Sep 15, 2010 at 00:57, Matthew Sacks matt...@matthewsacks.com wrote: Changing subject to VOTE On Sep 8, 2010, at 11:29 PM, Pid wrote: On 09/09/2010 07:15, Greg Stein wrote: Just to clarify: I'm assuming you're saying +1 to the proposal, rather than to my comment. Correct? +1 indeed, to the proposal +1 actually, to the mailing list comment, too. The Incubator PMC might consider that establishing sufficient interest which requires a user list is an indicator of a project approaching the exit criteria, or at least, making substantial progress. p And to clarify for myself: I have no opinion on the proposal itself. I timed out after Java and the next few buzzwords. Thankfully, this proposal didn't say framework or I may have timed out after the first :-P ... my comments were focused on the community aspects around mailing list management, and successfully growing a lively and sustainable critical mass. Cheers, -g On Thu, Sep 9, 2010 at 02:06, Pid p...@pidster.com wrote: +1 (non-binding) Small point: if a Mentor must be a Member, I can't be one, because I'm not. p On 08/09/2010 16:00, Mohammad Nour El-Din wrote: +1 (Notbinding) On Wed, Sep 8, 2010 at 7:22 AM, Greg Stein gst...@gmail.com wrote: On Tue, Sep 7, 2010 at 20:29, Matthew Sacks matt...@matthewsacks.comwrote: ... *Mailing Lists* kitty-dev kitty-commits kitty-user Is there a large user community already? If not, then splitting the community across dev/user does not make sense. You want to keep the users and developers on the same mailing list until one starts to overwhelm the other. By partitioning the lists too early, you risk never reaching critical mass on *either* mailing list. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 0x62590808.asc - 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
