Re: [DISCUSS] [PROPOSAL] Apache Monitoring
It sounds good. Regards JB On 09/25/2013 01:17 AM, Olivier Lamy wrote: So what about Baldr? BTW we can start incubation using Monitoring then change the name for TLP? WDYT? On 21 September 2013 06:30, Christian Grobmeier grobme...@gmail.com wrote: I would like to throw in this document: http://www.apache.org/foundation/marks/naming.html We should make a few tests already before we start the process officially. here is the current list, i felt so free to add a few comments already. - CoMon There is Common Software, a company. We might have a trademarks problem because of similarity. - Leitstand Not sure if I like the sound :-), but did not find any repositories at github. From the meaning, a Leitstand is usually something were you can adjust things (more power, less steam and so on). Monitoring would be only a part of it. But on the other hand, it expresses things well and it is a unused word so far. - Thor Great name, great god, but unfortunately a lot of people use that name for their code :-( - Balder / Baldur, also possible: Baldr I haven't see a lot with that name, but we need to check this more in detail. From that perspective, Leitstand would be the best catch from a unique point of view. I like Baldr very much from that meaning. Lets see if there are more names the next days. Romain Manni-Bucau schrieb: Why not CoMon? Remind commons monitoring, that's fun and closer to english so easier to propagate IMO. Le 20 sept. 2013 12:59, Jean-Baptiste Onofré j...@nanthrax.net a écrit : I like the Apache Leitstand name. Regards JB On 09/20/2013 09:51 AM, Tammo van Lessen wrote: So if German is en vogue already, I'd propose Apache Leitstand [1], which means control room. I think it would make also a nice name when pronounced in English. This of course only works if the GUI is an important piece of the project, which is the case if I understood correctly. Cheers, Tammo [1] http://de.wikipedia.org/wiki/**Leitstandhttp://de.wikipedia.org/wiki/Leitstand On Fri, Sep 20, 2013 at 3:23 AM, Olivier Lamy ol...@apache.org wrote: So It looks we have more interested folks. But before starting the vote I'd like to find an other name for the project. Someone proposed Baldur or Balder (note, It's a popular germanic god). So as a French guy this proposition looks to be rude for me :-). More seriously, this name doesn't hurt me. If any other propositions, it's time to speak. Cheers -- Olivier On 16 September 2013 08:25, Tammo van Lessen tvanles...@gmail.com wrote: Am 15.09.2013 15:35 schrieb Romain Manni-Bucau rmannibu...@gmail.com : Hi Angular is great but i hope well keep extensibility possible without js. In all case well get at least a thread on it to discuss about the stack we want and well use ;) Looking forward to that discussion ;) I'd prefer progressive enhancement over SPAs in this context as well. Or even http://roca-style.org. Tammo -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --**--** - To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The podling initial committers issue
Hi, On Wed, Sep 25, 2013 at 8:58 PM, Craig L Russell craig.russ...@oracle.com wrote: When a proposal is just a candidate, there are two possible approaches (for those interested in committership) IMO once the possible approaches are documented, we should require incoming podlings to choose one and indicate which one in the incubation proposal. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator
+1 from me (binding). G'luck! Cheers, Chris -Original Message- From: Jim Jagielski j...@jagunet.com Reply-To: general@incubator.apache.org general@incubator.apache.org, general@incubator.apache.org general@incubator.apache.org Date: Monday, September 23, 2013 5:44 AM To: general@incubator.apache.org general@incubator.apache.org Subject: [VOTE] Usergrid BaaS Stack for Apache Incubator After a useful and successful proposal cycle, I would like to propose a VOTE on accepting Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. Voting to run for 72+ hours... Here is a link to the proposal: https://wiki.apache.org/incubator/UsergridProposal It is also pasted below: = Usergrid Proposal = == Abstract == Usergrid is a multi-tenant Backend-as-a-Service stack for web mobile applications, based on RESTful APIs. == Proposal == Usergrid is an open-source Backend-as-a-Service (³BaaS² or ³mBaaS²) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services (user registration management, data storage, file storage, queues) and retrieval features (full text search, geolocation search, joins) to power common app features. It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment. For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise. == Background == Developing web or mobile applications obviously necessitates writing and maintaining more than just front-end code. Even simple applications can implicitly rely on server code being run to store users, perform database queries, serve images and video files, etc. Developing and maintaining such backend services requires skills not always available or expected of app development teams. Beyond that, the proliferation of apps inside of companies leads to the creation of many different, ad-hoc, unequally maintained backend solutions created by employees and contractors alike and hosted on a wide variety of environments. This is causing poor resource usage, operational issues, as well as security, privacy compliance concerns. In response to this problem, companies have long tried to standardize their server-side stack or unify them behind an ESB or API strategy. Backends-as-a-Service follow a similar approach but their unique characteristic is strongly tying 1) a persistence tier (typically a database), 2) a server-side application tier delivering a set of common services and 3) a set of client-side application interface mechanisms. For example, a BaaS could package 1) MongoDB with 2) a node.js application that offers access through 3) WebSockets. In the case of Usergrid, the trifecta is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API. The Backend-as-a-Service approach has steadily gained popularity in the last few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com, each operating tens of thousands of apps for tens of thousands of developers. The trend has already reached large organizations as well, with global companies such as Korea Telecom internally building a privately-run BaaS platform. But so far, there have been limited options for developers that want a non-proprietary, open option for hosting and providing these services themselves, or for enterprise and government users who want to provide these capabilities from their own data centers, especially on a very large scale. == Rationale == The issue this proposal deals with is implicit in the name. Backend-as-a-Service platforms are usually offered solely as proprietary cloud services. They are typically closed sourced, hosted on public clouds, and require subscription payment. Usergrid opens the playing field, by making a fully-featured BaaS platform freely available to all. This includes developers that previously could not afford them, such as mobile enthusiasts, small boutiques, and cost-sensitive startups. This also includes large companies that benefit from a reference implementation they can deploy in trust, or extend to their needs without losing time writing less-vetted, less-performant boilerplate functionality. Usergrid has been open source since 2011 and has grown as an independent project, garnering 11 primary committers, 35 total contributors, 260+ participants on its mailing list, with 3,700+ commits, 200+ external contributions, 350+ stars and 100+ forks on Github, not to mention several
Re: [VOTE] Release of Apache MRQL 0.9.0 incubating
This is a reminder that this vote is scheduled to close in about 24 hours out of 72 hours and we still have no binding votes from the Incubator PMC. This is our first release and we have spent a lot of time to migrate our old source code to the Apache infrastructure and to adapt the Apache policies in all parts of the project. Please vote on releasing Apache MRQL 0.9.0 incubating. Thank you Leonidas Fegaras On 09/24/2013 07:44 AM, Leonidas Fegaras wrote: Hello, This is a call for a vote on Apache MRQL 0.9.0 incubating. MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark. This is our first release. A vote was held on the MRQL developer mailing list and it passed with three +1 votes (plus one late vote), and zero -1 or 0 votes (see the vote thread [1] and result thread [2]), and now requires a vote on general@incubator.apache.org. The vote will be open for 72 hours (it will close on Friday 27/Sep/2013 at 1pm GMT) and passes if a majority of at least three +1 IPMC votes are cast. [ ] +1 Release this package as Apache MRQL 0.9.0-incubating [ ] -1 Do not release this package because... A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemrql-055/ You are voting only for the source distribution. The source tar ball is available at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-src-dist/0.9.0-incubating/ The release candidate consists of the following source distribution archives: - mrql-src-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 4b5c6c2df32881b77633303435cb0c99856105cd SHA1 of ZIP: edae1009a5ef7a7613f4da4d2d46e1c9339cb70f You can compile the sources using 'mvn package'. In addition, the following supplementary binary distributions are provided for user convenience at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-bin-dist/0.9.0-incubating/ The binary distribution archives are: - mrql-bin-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 27a1c569a0da333a22da260b07356673b81f539c SHA1 of ZIP: 6afdeb2640e6b3a31a97e44a0b5e585e6ade62ac The release candidate has been signed through the key 798764F1 in: http://www.apache.org/dist/incubator/mrql/KEYS http://keyserver.kjsl.org:11371/pks/lookup?op=getsearch=0xB7737C07798764F1 The release candidate is based on the sources tagged with MRQL-0.9.0-incubating-RC1: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tag;h=a7f69742a21393f98d951a8bc5822ae218ffda60 RAT output: http://people.apache.org/~fegaras/dist/MRQL-0.9.0-incubating-RC1/rat.txt Suitable name search: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-32 Note: The NOTICE includes the 3rd party copyright notices for JLine and CUP because the JLine and the CUP runtime libraries are bundled in the jar files in the MRQL binary distribution (files lib/*.jar). This was required because the MRQL jar files must contain all the dependencies in order to run on Hadoop and Hama. To learn more about Apache MRQL, please visit: http://wiki.apache.org/mrql/ Thanks, Leonidas Fegaras [1] http://markmail.org/message/nhyjdxlmas5vlg5x [2] http://markmail.org/message/5zsmncpimbdgfyn7 . - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Accept Aurora for Apache Incubation
Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been developed as a scheduler for Apache Mesos. Additionally, it relies on ZooKeeper for service discovery, allowing servers to register at a location and clients to subsequently discover the servers. == An Excessive Fascination with the Apache Brand == While we respect the reputation of the Apache brand and
Re: [VOTE] Release of Apache MRQL 0.9.0 incubating
On 24 September 2013 13:44, Leonidas Fegaras fega...@cse.uta.edu wrote: Hello, This is a call for a vote on Apache MRQL 0.9.0 incubating. MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark. This is our first release. A vote was held on the MRQL developer mailing list and it passed with three +1 votes (plus one late vote), and zero -1 or 0 votes (see the vote thread [1] and result thread [2]), and now requires a vote on general@incubator.apache.org. The vote will be open for 72 hours (it will close on Friday 27/Sep/2013 at 1pm GMT) and passes if a majority of at least three +1 IPMC votes are cast. [ ] +1 Release this package as Apache MRQL 0.9.0-incubating [ ] -1 Do not release this package because... A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemrql-055/ You are voting only for the source distribution. The source tar ball is available at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-src-dist/0.9.0-incubating/ The release candidate consists of the following source distribution archives: - mrql-src-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 4b5c6c2df32881b77633303435cb0c99856105cd SHA1 of ZIP: edae1009a5ef7a7613f4da4d2d46e1c9339cb70f You can compile the sources using 'mvn package'. In addition, the following supplementary binary distributions are provided for user convenience at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-bin-dist/0.9.0-incubating/ The binary distribution archives are: - mrql-bin-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 27a1c569a0da333a22da260b07356673b81f539c SHA1 of ZIP: 6afdeb2640e6b3a31a97e44a0b5e585e6ade62ac The release candidate has been signed through the key 798764F1 in: http://www.apache.org/dist/incubator/mrql/KEYS http://keyserver.kjsl.org:11371/pks/lookup?op=getsearch=0xB7737C07798764F1 The release candidate is based on the sources tagged with MRQL-0.9.0-incubating-RC1: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tag;h=a7f69742a21393f98d951a8bc5822ae218ffda60 That does not seem to be the correct tag, because the pom versions include -SNAPSHOT in them. RAT output: http://people.apache.org/~fegaras/dist/MRQL-0.9.0-incubating-RC1/rat.txt Suitable name search: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-32 The vote e-mail includes the hashes for tags and archives which is excellent, as it ties the vote to the items being voted on. So it's unfortunate that the tag does not agree with the source archive. Sigs and hashes seem OK to me. The name and description entries in the POMs should all start Apache MRQL so it is clear that they are part of the Apache MRQL product. This is necessary for clear branding. Also the name affects the generated NOTICE files under META-INF. These are currently invalid. It's a bit confusing to have artifact id of gen when all the other ids include MRQL or mrql. Note: The NOTICE includes the 3rd party copyright notices for JLine and CUP because the JLine and the CUP runtime libraries are bundled in the jar files in the MRQL binary distribution (files lib/*.jar). This was required because the MRQL jar files must contain all the dependencies in order to run on Hadoop and Hama. It's OK to bundle 3rd party jars (assuming that the license allows us to do so, so no GPL for example). However, the NOTICE and LICENSE files must only refer to the enclosing entity. Since the source archive does not contain CUP and JLine its NL files must not include references to them. Likewise the top level NL files in the Git repo should only refer to files actually contained in the repo. Also, the NOTICE file looks wrong even for the binary jar; at *most* two or 3 lines are needed for each external inclusion. See http://www.apache.org/dev/licensing-howto.html#mod-notice The licences must either be appended to the LICENSE file or you can store them in separate files which are linked from the main LICENSE file. Some of the POMs in the Nexus staging repo appear to have lost their AL headers. To learn more about Apache MRQL, please visit: http://wiki.apache.org/mrql/ Thanks, Leonidas Fegaras [1] http://markmail.org/message/nhyjdxlmas5vlg5x [2] http://markmail.org/message/5zsmncpimbdgfyn7 - 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] Accept Aurora for Apache Incubation
+1 for accepting Aurora. I'd like to contribute to aurora project as well. Thanks Sent from my iPad Chan On Sep 26, 2013, at 9:38 PM, Dave Lester d...@ischool.berkeley.edu wrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been
Re: [VOTE] Accept Aurora for Apache Incubation
+1 Looking forward to being a part of Aurora and its incubation -Jake On Thu, Sep 26, 2013 at 12:08 PM, Dave Lester d...@ischool.berkeley.eduwrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been developed as a scheduler for Apache Mesos. Additionally, it relies
Re: [VOTE] Release of Apache MRQL 0.9.0 incubating
Hi Sebastian, Thank you for checking our release. I think you clicked on the wrong tree link at our GIT repo. The source tree is: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tree;h=385ba2829bdf184886ac82b5db793f1264bbcf3c;hb=385ba2829bdf184886ac82b5db793f1264bbcf3c which corresponds exactly to the tag MRQL-0.9.0-incubating-RC1 as it is shown on our call for votes. These pom.xml files clearly have 0.9.0-incubating. So the link on our call was correct but you clicked on the wrong git tree on the GIT page (you got the latest tree). Also I am not sure about inserting 3rd party licenses on LICENSE. Spark did that but I think it was wrong. From what i've read, LICENSE should have only the Apache 2.0 license. Please look at LEGAL-177, where we discussed what to put in the MRQL NOTICE file. Please let us know if you consider the rest of the problems you mentioned blocking for this release as is. Thanks Leonidas Fegaras On Sep 26, 2013, at 11:45 AM, sebb wrote: On 24 September 2013 13:44, Leonidas Fegaras fega...@cse.uta.edu wrote: Hello, This is a call for a vote on Apache MRQL 0.9.0 incubating. MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark. This is our first release. A vote was held on the MRQL developer mailing list and it passed with three +1 votes (plus one late vote), and zero -1 or 0 votes (see the vote thread [1] and result thread [2]), and now requires a vote on general@incubator.apache.org. The vote will be open for 72 hours (it will close on Friday 27/Sep/2013 at 1pm GMT) and passes if a majority of at least three +1 IPMC votes are cast. [ ] +1 Release this package as Apache MRQL 0.9.0-incubating [ ] -1 Do not release this package because... A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemrql-055/ You are voting only for the source distribution. The source tar ball is available at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-src-dist/0.9.0-incubating/ The release candidate consists of the following source distribution archives: - mrql-src-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 4b5c6c2df32881b77633303435cb0c99856105cd SHA1 of ZIP: edae1009a5ef7a7613f4da4d2d46e1c9339cb70f You can compile the sources using 'mvn package'. In addition, the following supplementary binary distributions are provided for user convenience at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-bin-dist/0.9.0-incubating/ The binary distribution archives are: - mrql-bin-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 27a1c569a0da333a22da260b07356673b81f539c SHA1 of ZIP: 6afdeb2640e6b3a31a97e44a0b5e585e6ade62ac The release candidate has been signed through the key 798764F1 in: http://www.apache.org/dist/incubator/mrql/KEYS http://keyserver.kjsl.org:11371/pks/lookup?op=getsearch=0xB7737C07798764F1 The release candidate is based on the sources tagged with MRQL-0.9.0-incubating-RC1: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tag;h=a7f69742a21393f98d951a8bc5822ae218ffda60 That does not seem to be the correct tag, because the pom versions include -SNAPSHOT in them. RAT output: http://people.apache.org/~fegaras/dist/MRQL-0.9.0-incubating-RC1/rat.txt Suitable name search: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-32 The vote e-mail includes the hashes for tags and archives which is excellent, as it ties the vote to the items being voted on. So it's unfortunate that the tag does not agree with the source archive. Sigs and hashes seem OK to me. The name and description entries in the POMs should all start Apache MRQL so it is clear that they are part of the Apache MRQL product. This is necessary for clear branding. Also the name affects the generated NOTICE files under META-INF. These are currently invalid. It's a bit confusing to have artifact id of gen when all the other ids include MRQL or mrql. Note: The NOTICE includes the 3rd party copyright notices for JLine and CUP because the JLine and the CUP runtime libraries are bundled in the jar files in the MRQL binary distribution (files lib/*.jar). This was required because the MRQL jar files must contain all the dependencies in order to run on Hadoop and Hama. It's OK to bundle 3rd party jars (assuming that the license allows us to do so, so no GPL for example). However, the NOTICE and LICENSE files must only refer to the enclosing entity. Since the source archive does not contain CUP and JLine its NL files must not include references to them. Likewise the top level NL files in the Git repo should only refer to files actually contained in the repo. Also, the NOTICE file looks wrong even for the binary jar; at *most* two or 3 lines are needed for each external inclusion. See
Re: [VOTE] Accept Aurora for Apache Incubation
+1 (binding) On Thu, Sep 26, 2013 at 9:08 AM, Dave Lester d...@ischool.berkeley.edu wrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been developed as a scheduler for Apache Mesos. Additionally, it relies on ZooKeeper for service discovery, allowing servers to
Re: [VOTE] Release of Apache MRQL 0.9.0 incubating
On 26 September 2013 18:44, Leonidas Fegaras fega...@cse.uta.edu wrote: Hi Sebastian, Thank you for checking our release. I think you clicked on the wrong tree link at our GIT repo. The source tree is: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tree;h=385ba2829bdf184886ac82b5db793f1264bbcf3c;hb=385ba2829bdf184886ac82b5db793f1264bbcf3c which corresponds exactly to the tag MRQL-0.9.0-incubating-RC1 as it is shown on our call for votes. The URL I clicked on was as follows which was in the first message of this vote e-mail thread: quote The release candidate is based on the sources tagged with MRQL-0.9.0-incubating-RC1: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tag;h=a7f69742a21393f98d951a8bc5822ae218ffda60 /quote I then clicked on tree and then pom.xml / raw I agree that the URL you have just provided has a pom that looks OK. But that URL was not in the original vote e-mail.. These pom.xml files clearly have 0.9.0-incubating. So the link on our call was correct but you clicked on the wrong git tree on the GIT page (you got the latest tree). No, see above - the original e-mail link was wrong. Also I am not sure about inserting 3rd party licenses on LICENSE. Spark did that but I think it was wrong. From what i've read, LICENSE should have only the Apache 2.0 license. No, the LICENSE file should have ALL the relevant licenses, either included or linked therefrom. Please look at LEGAL-177, where we discussed what to put in the MRQL NOTICE file. I already commented on that very issue. Please let us know if you consider the rest of the problems you mentioned blocking for this release as is. Yes, I do consider that the NL issues are blocking. The NL files must relate to the included bits and nothing more. The NOTICE file must include required notices and nothing more. Does the MRQL source contain any 3rd party code? If so, what, and where are the files? It looks as though some of the MRQL jar files contain JLine and CUP runtime. That seems wrong; Maven jar dependencies should be resolved using the dependency mechanism. Also, if the jars can be used together, there will be multiple copies of the classes, which is not good. Also, combining the 3rd party libraries with the MRQL code means that users cannot obtain just the binaries for MRQL itself; they will be forced to build it themselves. If there is a need to provide a bundled binary containing 3rd party jars, that is normally done in the zip/tar.gz archives containing the various components as individual jars. Thanks Leonidas Fegaras On Sep 26, 2013, at 11:45 AM, sebb wrote: On 24 September 2013 13:44, Leonidas Fegaras fega...@cse.uta.edu wrote: Hello, This is a call for a vote on Apache MRQL 0.9.0 incubating. MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark. This is our first release. A vote was held on the MRQL developer mailing list and it passed with three +1 votes (plus one late vote), and zero -1 or 0 votes (see the vote thread [1] and result thread [2]), and now requires a vote on general@incubator.apache.org. The vote will be open for 72 hours (it will close on Friday 27/Sep/2013 at 1pm GMT) and passes if a majority of at least three +1 IPMC votes are cast. [ ] +1 Release this package as Apache MRQL 0.9.0-incubating [ ] -1 Do not release this package because... A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemrql-055/ You are voting only for the source distribution. The source tar ball is available at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-src-dist/0.9.0-incubating/ The release candidate consists of the following source distribution archives: - mrql-src-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 4b5c6c2df32881b77633303435cb0c99856105cd SHA1 of ZIP: edae1009a5ef7a7613f4da4d2d46e1c9339cb70f You can compile the sources using 'mvn package'. In addition, the following supplementary binary distributions are provided for user convenience at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-bin-dist/0.9.0-incubating/ The binary distribution archives are: - mrql-bin-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 27a1c569a0da333a22da260b07356673b81f539c SHA1 of ZIP: 6afdeb2640e6b3a31a97e44a0b5e585e6ade62ac The release candidate has been signed through the key 798764F1 in: http://www.apache.org/dist/incubator/mrql/KEYS http://keyserver.kjsl.org:11371/pks/lookup?op=getsearch=0xB7737C07798764F1 The release candidate is based on the sources tagged with MRQL-0.9.0-incubating-RC1: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tag;h=a7f69742a21393f98d951a8bc5822ae218ffda60 That does not seem to be the correct tag, because the pom versions
[CANCELED] [VOTE] Release of Apache MRQL 0.9.0 incubating
Hi all, This vote is canceled due to the problems found in this release (the most important of which is that the content of LICENSE NOTICE files of the provided artifacts was found to be wrong). We will fix all these issues and we will generate a new release candidate. My thanks to all who looked at our release artifacts carefully and for letting us know the problems. Leonidas Fegaras On Sep 24, 2013, at 7:44 AM, Leonidas Fegaras wrote: Hello, This is a call for a vote on Apache MRQL 0.9.0 incubating. MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark. This is our first release. A vote was held on the MRQL developer mailing list and it passed with three +1 votes (plus one late vote), and zero -1 or 0 votes (see the vote thread [1] and result thread [2]), and now requires a vote on general@incubator.apache.org. The vote will be open for 72 hours (it will close on Friday 27/Sep/2013 at 1pm GMT) and passes if a majority of at least three +1 IPMC votes are cast. [ ] +1 Release this package as Apache MRQL 0.9.0-incubating [ ] -1 Do not release this package because... A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemrql-055/ You are voting only for the source distribution. The source tar ball is available at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-src-dist/0.9.0-incubating/ The release candidate consists of the following source distribution archives: - mrql-src-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 4b5c6c2df32881b77633303435cb0c99856105cd SHA1 of ZIP: edae1009a5ef7a7613f4da4d2d46e1c9339cb70f You can compile the sources using 'mvn package'. In addition, the following supplementary binary distributions are provided for user convenience at: https://repository.apache.org/content/repositories/orgapachemrql-055/org/apache/mrql/mrql-bin-dist/0.9.0-incubating/ The binary distribution archives are: - mrql-bin-dist-0.9.0-incubating.[zip|tar.gz] SHA1 of TGZ: 27a1c569a0da333a22da260b07356673b81f539c SHA1 of ZIP: 6afdeb2640e6b3a31a97e44a0b5e585e6ade62ac The release candidate has been signed through the key 798764F1 in: http://www.apache.org/dist/incubator/mrql/KEYS http://keyserver.kjsl.org:11371/pks/lookup?op=getsearch=0xB7737C07798764F1 The release candidate is based on the sources tagged with MRQL-0.9.0-incubating-RC1: https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=tag;h=a7f69742a21393f98d951a8bc5822ae218ffda60 RAT output: http://people.apache.org/~fegaras/dist/MRQL-0.9.0-incubating-RC1/rat.txt Suitable name search: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-32 Note: The NOTICE includes the 3rd party copyright notices for JLine and CUP because the JLine and the CUP runtime libraries are bundled in the jar files in the MRQL binary distribution (files lib/*.jar). This was required because the MRQL jar files must contain all the dependencies in order to run on Hadoop and Hama. To learn more about Apache MRQL, please visit: http://wiki.apache.org/mrql/ Thanks, Leonidas Fegaras [1] http://markmail.org/message/nhyjdxlmas5vlg5x [2] http://markmail.org/message/5zsmncpimbdgfyn7
Process for Granting Jenkins Access
A Mentoring question. Some of the committers in a podling want to access Jenkins. The instructions are here: http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account I take it that for a podling any of the mentors should take the role of the PMC Chair and do this action. Please let me know if the Incubator process is otherwise. Regards, Dave - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process for Granting Jenkins Access
Hey Dave You are correct, but the mentor would have to have the ability to edit ldap perms and hopefully an understanding that by enabling the hudson-jobadmin karma that the user would be able to configure any job within jenkins and not just that specific projects jobs. When enabling this for someone I usually look to see if they are on the PMC for that project or ask someone on that PMC if that user has earned such a karma grant (not their first commit to the project). When in doubt you can ask the builds@ list or anyone on infra for help -Jake On Thu, Sep 26, 2013 at 5:37 PM, Dave Fisher dave2w...@comcast.net wrote: A Mentoring question. Some of the committers in a podling want to access Jenkins. The instructions are here: http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account I take it that for a podling any of the mentors should take the role of the PMC Chair and do this action. Please let me know if the Incubator process is otherwise. Regards, Dave - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aurora for Apache Incubation
+1 On Sep 26, 2013, at 9:08 AM, Dave Lester d...@ischool.berkeley.edu wrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been developed as a scheduler for Apache Mesos. Additionally, it relies on ZooKeeper for service discovery, allowing servers to register at a
Re: [VOTE] Accept Aurora for Apache Incubation
+1 (binding) On Thu, Sep 26, 2013 at 9:08 AM, Dave Lester d...@ischool.berkeley.eduwrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been developed as a scheduler for Apache Mesos. Additionally, it relies on ZooKeeper for service discovery, allowing servers to
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator
+1 (non-binding). Thanks Raminder On Sep 26, 2013, at 11:04 AM, Chris Mattmann mattm...@apache.org wrote: +1 from me (binding). G'luck! Cheers, Chris -Original Message- From: Jim Jagielski j...@jagunet.com Reply-To: general@incubator.apache.org general@incubator.apache.org, general@incubator.apache.org general@incubator.apache.org Date: Monday, September 23, 2013 5:44 AM To: general@incubator.apache.org general@incubator.apache.org Subject: [VOTE] Usergrid BaaS Stack for Apache Incubator After a useful and successful proposal cycle, I would like to propose a VOTE on accepting Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. Voting to run for 72+ hours... Here is a link to the proposal: https://wiki.apache.org/incubator/UsergridProposal It is also pasted below: = Usergrid Proposal = == Abstract == Usergrid is a multi-tenant Backend-as-a-Service stack for web mobile applications, based on RESTful APIs. == Proposal == Usergrid is an open-source Backend-as-a-Service (³BaaS² or ³mBaaS²) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services (user registration management, data storage, file storage, queues) and retrieval features (full text search, geolocation search, joins) to power common app features. It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment. For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise. == Background == Developing web or mobile applications obviously necessitates writing and maintaining more than just front-end code. Even simple applications can implicitly rely on server code being run to store users, perform database queries, serve images and video files, etc. Developing and maintaining such backend services requires skills not always available or expected of app development teams. Beyond that, the proliferation of apps inside of companies leads to the creation of many different, ad-hoc, unequally maintained backend solutions created by employees and contractors alike and hosted on a wide variety of environments. This is causing poor resource usage, operational issues, as well as security, privacy compliance concerns. In response to this problem, companies have long tried to standardize their server-side stack or unify them behind an ESB or API strategy. Backends-as-a-Service follow a similar approach but their unique characteristic is strongly tying 1) a persistence tier (typically a database), 2) a server-side application tier delivering a set of common services and 3) a set of client-side application interface mechanisms. For example, a BaaS could package 1) MongoDB with 2) a node.js application that offers access through 3) WebSockets. In the case of Usergrid, the trifecta is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API. The Backend-as-a-Service approach has steadily gained popularity in the last few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com, each operating tens of thousands of apps for tens of thousands of developers. The trend has already reached large organizations as well, with global companies such as Korea Telecom internally building a privately-run BaaS platform. But so far, there have been limited options for developers that want a non-proprietary, open option for hosting and providing these services themselves, or for enterprise and government users who want to provide these capabilities from their own data centers, especially on a very large scale. == Rationale == The issue this proposal deals with is implicit in the name. Backend-as-a-Service platforms are usually offered solely as proprietary cloud services. They are typically closed sourced, hosted on public clouds, and require subscription payment. Usergrid opens the playing field, by making a fully-featured BaaS platform freely available to all. This includes developers that previously could not afford them, such as mobile enthusiasts, small boutiques, and cost-sensitive startups. This also includes large companies that benefit from a reference implementation they can deploy in trust, or extend to their needs without losing time writing less-vetted, less-performant boilerplate functionality. Usergrid has been open source since 2011 and has grown as an
Re: [VOTE] Accept Aurora for Apache Incubation
+1 (non-binding) On Thu, Sep 26, 2013 at 9:38 PM, Dave Lester d...@ischool.berkeley.eduwrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core committers and contributors. == Relationships with Other Apache Products == Initially, Aurora has been developed as a scheduler for Apache Mesos. Additionally, it relies on ZooKeeper for service discovery, allowing servers to
Re: [VOTE] Accept Aurora for Apache Incubation
+1. Milinda On Thu, Sep 26, 2013 at 11:23 PM, Ashish paliwalash...@gmail.com wrote: +1 (non-binding) On Thu, Sep 26, 2013 at 9:38 PM, Dave Lester d...@ischool.berkeley.edu wrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core
Re: [VOTE] Accept Aurora for Apache Incubation
+1 On Thu, Sep 26, 2013 at 11:44 PM, Benjamin Hindman benjamin.hind...@gmail.com wrote: +1 (binding) On Thu, Sep 26, 2013 at 9:08 AM, Dave Lester d...@ischool.berkeley.edu wrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other companies who have expressed an interest in Aurora. == Reliance on Salaried Developers == Initial Aurora committers are salaried developers at Twitter, however shortly after open sourcing the code we plan to diversify the project’s core
[RESULT][VOTE] Apache Chukwa graduation as TLP
Graduation community vote passed with 7 +1 from , which from those 6 are binding : Jean-Baptiste Onofre Ant Elder Christian Grobmeier Jukka Zitting Luciano Resende Alan D. Cabrera Jie Huang (non-binding) I'll check the status of the resolution and continue the process on the IPMC. Thanks regards, Eric On Tue, Sep 24, 2013 at 6:47 AM, Alan D. Cabrera l...@toolazydogs.comwrote: +1 - binding Regards, Alan On Sep 20, 2013, at 10:52 AM, Eric Yang ey...@apache.org wrote: [ ] +1 Graduate Chukwa podling from Incubator [ ] +0 Indifferent to graduation status of Chukwa [ ] -1 Reject graduation of Chukwa podling from Incubator because ...
Re: [VOTE] Accept Aurora for Apache Incubation
+1 -- Ross Allen On Thu, Sep 26, 2013 at 8:22 PM, Nirmal Fernando nirmal070...@apache.orgwrote: +1 On Thu, Sep 26, 2013 at 11:44 PM, Benjamin Hindman benjamin.hind...@gmail.com wrote: +1 (binding) On Thu, Sep 26, 2013 at 9:08 AM, Dave Lester d...@ischool.berkeley.edu wrote: Since discussion about the Aurora proposal has calmed and the team recently published a snapshot of the their source code on github ( https://github.com/twitter/aurora), I'd like to call a vote for Aurora to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/AuroraProposal Let's keep this vote open for three business days, closing the voting on Tuesday 10/1. [ ] +1 Accept Aurora into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Aurora because... Dave = Abstract = Aurora is a service scheduler used to schedule jobs onto Apache Mesos. = Proposal = Aurora is a scheduler that provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. Aurora builds on top of Apache Mesos and provides common features that allow any site to run large scale production applications. While the project is currently used in production at Twitter, we wish to develop a community to increase contributions and see it thrive in the future. = Background = The initial development of Aurora was done at Twitter, and its codebase was recently open sourced. This proposal is for Aurora to join the Apache Incubator. = Rationale = While the Apache Mesos core focuses on distributing individual tasks across nodes in a cluster, typical services consist of dozens or hundreds of replicas of tasks. As a service scheduler, Aurora provides the abstraction of a job to bundle and manage these tasks. Aurora provides many key functionalities centered around a job, including: definition, the concept of an instance and the serverset, deployment and scheduling, health checking, and introspection. It also allows cross-cutting concerns to be handled like observability and log collection. = Current Status = == Meritocracy == By submitting this incubator proposal, we’re expressing our intent to build a diverse developer community around Aurora that will conduct itself according to The Apache Way and use meritocratic means of accepting contributions. Several members of the Aurora team overlap with Apache Mesos, which successfully graduated from the Incubator and has embraced a meritocratic model of governance; we plan to follow a similar path forward with Aurora and believe that a synergy between both projects will make this even easier. == Community == Aurora is currently being used internally at Twitter. By open sourcing the project, we hope to extend our contributor base significantly and create a vibrant community around the project. == Core Developers == Aurora is currently being developed by a team of seven engineers at Twitter. == Alignment == The ASF is a natural choice to host the Aurora project, given the goal of open sourcing the project and fostering a community to grow and support the software. Additionally, Aurora integrates with Apache Mesos, and Apache ZooKeeper for service discovery. We believe that inclusion within Apache will build stronger ties between these projects, and create further alignment between their goals and communities. = Known Risks = == Orphaned Products == The core developers plan to continue working full time on the project, and there is very little risk of Aurora being abandoned since it is running hundreds of services as part of Twitter’s infrastructure. Additionally, members of the Mesos community beyond Twitter have expressed interest in an advanced scheduler like Aurora (see “Interested Parties” section); we believe that need will drive some of the community involvement necessary for the project to incubate successfully. == Inexperience with Open Source == Initial Aurora committers have varying levels of experience using and contributing to Open Source projects, however by working with our mentors and the Apache community we believe we will be able to conduct ourselves in accordance with Apache Incubator guidelines. The close relationship between the Aurora team and Apache Mesos means there is an awareness of the incubation process and a willingness to embrace The Apache Way. == Homogenous Developers == The initial set of committers are from a single organization, however we expect that once approved for incubation the project will attract contributors from more organizations. We have already had conversations with other
