Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
+1 Bertrand
[VOTE] Apache Kalumet 0.6-incubating release (3rd try)
Hi all, Apache Kalumet 0.6-incubating release has been voted by the Kalumet podling PMC. I forward the release to the Incubator for final vote. Please find the RELEASE NOTES and staging repository in the original message. Thanks, Regards JB Original Message Subject: [VOTE] Apache Kalumet 0.6-incubating release (3rd try) Date: Thu, 05 Sep 2013 13:30:42 +0200 From: Jean-Baptiste Onofré j...@nanthrax.net Reply-To: kalumet-...@incubator.apache.org To: kalumet-...@incubator.apache.org Hi all, The first release of Kalumet (0.6-incubating) is available. Please take a look on the artifacts (especially the distribution archives), review the documentation and make a try. Release Notes: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/RELEASE-NOTES Staging repository: https://repository.apache.org/content/repositories/orgapachekalumet-013/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Do not approve the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- 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: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
On Mon, Sep 30, 2013 at 03:27:24PM -0400, Dave wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. +1 (binding) - 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 (revised proposal)
On Mon, Sep 30, 2013 at 9:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. +1 (non-binding) I hope to be able to contribute to this project during incubation. Lieven - 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 (revised proposal)
+1 (binding) - 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 (revised proposal)
+1 binding Regards, Alan - 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 (revised proposal)
+1 (non-binding) On Tue, Oct 1, 2013 at 1:09 AM, Lieven Govaerts lieven.govae...@gmail.comwrote: On Mon, Sep 30, 2013 at 9:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. +1 (non-binding) I hope to be able to contribute to this project during incubation. Lieven - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc updated to mention this. Jordan Zimmerman On Sep 30, 2013, at 9:21 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I reckon that this is one of the initial steps of becoming a top-level project (TLP). See the board resolution that created your TLP: hereby is tasked with the creation of a set of bylaws to ... Thanks for clearing that up. Yes it was mentioned in the resolution, we should get to it then. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 7:50 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc updated to mention this. I hope that most projects won't bother. We need rules because we need a framework to resolve disagreements, but bylaws are really hard to get right and every little flaw is an opportunity to waste time arguing over legislative minutia. Projects which inherit as many well-exercised rules as possible from the foundation rather than creating their own rules ex nihilo get to spend less time debugging legalese. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
+1 to Marvin's I hope that most projects won't bother although there needs to be something a little more than a blank piece of paper. The best approach, IMHO, is to simply make it official that the project adopts the same byelaws as project x, y or z. Pick an established project that has a minimal set of stable byelaws and go on from there. Some projects like to refer to the original project pages, others make a local copy. Both approaches have their advantages. The important thing to note is that, in my experience there is very little that changes from one project to the next given that we try to minimize the number of rules we wrap a project in. Probably the only item I see regular disagreement between projects is how much merit is needed for committership and then PMC membership but even this should not be codified into the byelaws since projects tend to change the height of the barrier over time. All we need is a way to decide if someone is a committer/PMC member. Ross Ross Gardler (@rgardler) Senior Technology Evangelist Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation On 1 October 2013 08:13, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Oct 1, 2013 at 7:50 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc updated to mention this. I hope that most projects won't bother. We need rules because we need a framework to resolve disagreements, but bylaws are really hard to get right and every little flaw is an opportunity to waste time arguing over legislative minutia. Projects which inherit as many well-exercised rules as possible from the foundation rather than creating their own rules ex nihilo get to spend less time debugging legalese. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Aurora accepted for Apache incubation
The vote for Aurora to become an incubated project has passed with 8 +1 binding votes, 8 +1 non-binding votes, and no -1 or 0 votes. *Binding +1 Votes:* Jake Farrell Henry Saputra Benjamin Hindman Chris Mattmann Alan D. Cabrera Andrei Savu Olivier Lamy Bertrand Delacretaz *Non-Binding +1 Votes:* Dulitha R. Wijewantha Ashish Paliwal Milinda Pathirage Nirmal Fernando Ross Allen Vinod Kone Andy Konwinski Benjamin Mahler Congrats to all involved! Best, Dave
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
+1 (non-binding). Thanks Raminder On Sep 30, 2013, at 3:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. The original proposal has been revised to name Dave Johnson as the Champion and to bring Jim Jagielski back in as a Mentor and to add John Lewis Mcgibbney as a Mentor. I also add some text to the Initial Committers section and a new Interested Contributors section to list those who have expressed interest in contributing. Here is a link to the revised 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
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 5:28 PM, Ross Gardler rgard...@opendirective.com wrote: +1 to Marvin's I hope that most projects won't bother although there needs to be something a little more than a blank piece of paper. The best approach, IMHO, is to simply make it official that the project adopts the same byelaws as project x, y or z. Pick an established project that has a minimal set of stable byelaws and go on from there. Some projects like to refer to the original project pages, others make a local copy. Both approaches have their advantages. At Wicket we didn't bother to pick bylaws and from what I have seen in other communities we are better for it. Graduation from the incubator is a testament that the community acts as a meritocracy, and the bylaws of the foundation should be good for all graduated projects. As a community I think that Wicket developers never even bothered to look at the bylaws and just follow the established processes and guidances that trickle down from board@. Looking at httpd, they don't have explicit bylaws either–my google fu did not unearth any document at httpd.apache.org that constitutes bylaws. Martijn - 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 (revised proposal)
+1 (binding) On Tue, Oct 1, 2013 at 6:03 PM, Raminder Singh rsand...@gmail.com wrote: +1 (non-binding). Thanks Raminder On Sep 30, 2013, at 3:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. The original proposal has been revised to name Dave Johnson as the Champion and to bring Jim Jagielski back in as a Mentor and to add John Lewis Mcgibbney as a Mentor. I also add some text to the Initial Committers section and a new Interested Contributors section to list those who have expressed interest in contributing. Here is a link to the revised 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] Usergrid BaaS Stack for Apache Incubator (revised proposal)
On Mon, Sep 30, 2013 at 3:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. +1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Kalumet 0.6-incubating release (3rd try)
On 1 October 2013 08:00, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, Apache Kalumet 0.6-incubating release has been voted by the Kalumet podling PMC. I forward the release to the Incubator for final vote. Please find the RELEASE NOTES and staging repository in the original message. Thanks, Regards JB Original Message Subject: [VOTE] Apache Kalumet 0.6-incubating release (3rd try) Date: Thu, 05 Sep 2013 13:30:42 +0200 From: Jean-Baptiste Onofré j...@nanthrax.net Reply-To: kalumet-...@incubator.apache.org To: kalumet-...@incubator.apache.org Hi all, The first release of Kalumet (0.6-incubating) is available. Please take a look on the artifacts (especially the distribution archives), review the documentation and make a try. Release Notes: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/RELEASE-NOTES Staging repository: https://repository.apache.org/content/repositories/orgapachekalumet-013/ Where is the KEYS file? The URL should be included in all votes so reviewers can check the sigs. The vote e-mail should also include the SCM co-ordinates (SVN URL+revision or GIT URL+hash). This is so the source archive contents can be checked against it. Also, the Nexus URLs are temporary (and not unique), so the hashes of the source archives should be included in the vote e-mail. Otherwise there is not way to tie the vote e-mail to the artifacts that are being voted on. Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Do not approve the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Marmotta 3.1.0-incubating
On 30 September 2013 11:17, Sebastian Schaffert sschaff...@apache.org wrote: Dear all, After several months of work since the last incubating release (3.0.0-incubating) in April, we are now ready to release version 3.1.0-incubating. We fixed all the remaining issues that have been discussed in April (see thread [1]) plus many more technical issues. We have already held a vote that was open for more than 72 hours on the Apache Marmotta developer mailinglist [2]. The vote concluded [3] with 7 positive votes, of which 2 have been binding from IPMC members (Andy and Nandana) and the remaining 5 from the Apache Marmotta developers. I'd therefore like to ask the general incubator to check our release candidate. The release notes are available at the Jira Issue Tracker [4]. The vote form is included at the bottom of this mail. Greetings, Sebastian [1] http://apache.markmail.org/message/5tieelmeevi2j6xb [2] http://apache.markmail.org/message/lk3hc3jutoaxp6dr [3] http://apache.markmail.org/message/fvytzho2pnhasw2c [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314321version=12324026 === A candidate for the Marmotta 3.1.0-incubating release is available at: https://dist.apache.org/repos/dist/dev/incubator/marmotta/3.1.0-incubating/ The release candidate is based on the sources tagged with 3.1.0-incubating in: https://git-wip-us.apache.org/repos/asf/incubator-marmotta.git What is the hash of the tag please? Tags are not immutable, so should be included in the vote e-mail for the record. The release candidate consists of the following source distribution archives: - apache-marmotta-3.1.0- incubating-src.[zip|tar.gz] SHA1 of ZIP: 763c39dc9d7eb1c7d8fad83742b08f44b6fa5527 SHA1 of TGZ: 0f7f3395f22aeeaa4a402f1b08048c84899d9729 In addition, the following supplementary binary distributions are provided: - apache-marmotta-3.1.0-incubating-installer.[zip|tar.gz] SHA1 of ZIP: d7417a711a7f80eb29eb93ec75744a314fcf2edd SHA1 of TGZ: 4606fe743f607215dd4f3f39d8506852f529b617 - apache-marmotta-3.1.0-incubating-ldpath.[zip|tar.gz] SHA1 of ZIP: 4f4db937e0064a4393039b6fb8277be166a971ab SHA1 of TGZ: 5d63f972df2306afec96aa1a8931c4d0dabb2f75 - apache-marmotta-3.1.0-incubating-webapp.[zip|tar.gz] SHA1 of ZIP: e8e168a29e398cda9220a793958b825a906a3142 SHA1 of TGZ: 80d022d316e727b5f011069eec6dc9793b174838 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemarmotta-092/ Please vote on releasing this package as Apache Marmotta 3.1.0-incubating. The vote is open for the next 72 hours and passes if a majority of at least three +1 Marmotta PMC votes are cast. [ ] +1 Release this package as Apache Marmotta 3.1.0-incubating [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... === Release Notes - Marmotta - Version 3.1-incubating ** Sub-task * [MARMOTTA-216] - Implement JOIN improvements * [MARMOTTA-217] - Implement FILTER improvements * [MARMOTTA-218] - Integrate in marmotta-sparql ** Bug * [MARMOTTA-28] - Implement tests for core that take into account triple store changes * [MARMOTTA-63] - Triplestore: garbage collector for nodes currently not working properly * [MARMOTTA-66] - Rework sesame-commons ResourceUtils * [MARMOTTA-143] - unable to import big files * [MARMOTTA-150] - BNodes are a dead end in the Linked Data Explorer * [MARMOTTA-154] - Youtube video provider doesn't fetch the keywords * [MARMOTTA-155] - 3-char lang-tags are not accepted * [MARMOTTA-156] - Add Logback configuration to all tests to enable/disable debug logging * [MARMOTTA-170] - file-store (meta) for ldcache-backend-file contains wrong comments * [MARMOTTA-171] - remove legacy subdirs from src/main/webapp in marmotta-webapp * [MARMOTTA-186] - LDPath parser fails on local names that contain '.' * [MARMOTTA-187] - ldpath extension for CM does not recognize local names with '.' or '-' * [MARMOTTA-191] - SPARQL graph results fails under some circunstances * [MARMOTTA-197] - ldpath is loosing brackets on re-serialisation * [MARMOTTA-204] - Update to Sesame 2.7.1 * [MARMOTTA-205] - Turtle-Exports do not contain any language tags * [MARMOTTA-206] - Strictly follow the standard formatting on the NOTICE * [MARMOTTA-208] - Meta Put Webservice Deleting Tuples Incorrectly * [MARMOTTA-213] - Address the issues on our NOTICE files * [MARMOTTA-214] - Memento timestamp does not use the right template * [MARMOTTA-221] - ldpath is loosing quotes for StringConstants on re-serialisation * [MARMOTTA-225] - Serializing ldpath field mappings with URIs as fieldname does not work correctly * [MARMOTTA-227] - Snorql uses
Re: [VOTE] Apache Kalumet 0.6-incubating release (3rd try)
Hi Seb, Thanks for the update: 1/ KEYS file is here: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/KEYS 2/ SVN URLs: SCM Codebase: http://svn.apache.org/repos/asf/incubator/kalumet/branches/0.6.x/ Release Tag: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/ 3/ The source archives signature files are on the staging repository (including md5 and sha1 hash): https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/apache-kalumet/0.6-incubating/apache-kalumet-0.6-incubating-src.tar.gz.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/apache-kalumet/0.6-incubating/apache-kalumet-0.6-incubating-src.zip.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/controller/org.apache.kalumet.controller.core/0.6-incubating/org.apache.kalumet.controller.core-0.6-incubating-sources.jar.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/controller/org.apache.kalumet.controller.jboss/0.6-incubating/org.apache.kalumet.controller.jboss-0.6-incubating-sources.jar https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/controller/org.apache.kalumet.controller.weblogic/0.6-incubating/org.apache.kalumet.controller.weblogic-0.6-incubating-sources.jar https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/controller/org.apache.kalumet.controller.websphere/0.6-incubating/org.apache.kalumet.controller.websphere-0.6-incubating-sources.jar https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/kalumet/0.6-incubating/kalumet-0.6-incubating-source-release.zip.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/org.apache.kalumet.agent/0.6-incubating/org.apache.kalumet.agent-0.6-incubating-sources.jar.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/org.apache.kalumet.common/0.6-incubating/org.apache.kalumet.common-0.6-incubating-sources.jar.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/org.apache.kalumet.console/0.6-incubating/org.apache.kalumet.console-0.6-incubating-sources.jar.asc https://repository.apache.org/content/repositories/orgapachekalumet-013/org/apache/kalumet/org.apache.kalumet.utils/0.6-incubating/org.apache.kalumet.utils-0.6-incubating-sources.jar.asc Thanks again Seb for the reminder, Regards JB On 10/01/2013 06:55 PM, sebb wrote: On 1 October 2013 08:00, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, Apache Kalumet 0.6-incubating release has been voted by the Kalumet podling PMC. I forward the release to the Incubator for final vote. Please find the RELEASE NOTES and staging repository in the original message. Thanks, Regards JB Original Message Subject: [VOTE] Apache Kalumet 0.6-incubating release (3rd try) Date: Thu, 05 Sep 2013 13:30:42 +0200 From: Jean-Baptiste Onofré j...@nanthrax.net Reply-To: kalumet-...@incubator.apache.org To: kalumet-...@incubator.apache.org Hi all, The first release of Kalumet (0.6-incubating) is available. Please take a look on the artifacts (especially the distribution archives), review the documentation and make a try. Release Notes: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/RELEASE-NOTES Staging repository: https://repository.apache.org/content/repositories/orgapachekalumet-013/ Where is the KEYS file? The URL should be included in all votes so reviewers can check the sigs. The vote e-mail should also include the SCM co-ordinates (SVN URL+revision or GIT URL+hash). This is so the source archive contents can be checked against it. Also, the Nexus URLs are temporary (and not unique), so the hashes of the source archives should be included in the vote e-mail. Otherwise there is not way to tie the vote e-mail to the artifacts that are being voted on. Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Do not approve the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- 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 - 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:
Re: [VOTE] Apache Kalumet 0.6-incubating release (3rd try)
On 1 October 2013 18:07, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Seb, Thanks for the update: 1/ KEYS file is here: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/KEYS 2/ SVN URLs: SCM Codebase: http://svn.apache.org/repos/asf/incubator/kalumet/branches/0.6.x/ OK, but not relevant to the release vote. Release Tag: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/ SVN tags are not immutable. What is the revision number of the tag? 3/ The source archives signature files are on the staging repository (including md5 and sha1 hash): Yes, I know that. But when the staging repo is published (assuming that the vote passes), all the URLs listed below will become invalid. It won't be possible to tie the vote to the archives. The vote e-mail needs the actual hashes (either MD5 and/or SHA1) of the source archives. For example: apache-kalumet-0.6-incubating-src.zip MD5: 5664ebc70172b3b66f17d3a3db48594d Thanks again Seb for the reminder, Regards JB On 10/01/2013 06:55 PM, sebb wrote: On 1 October 2013 08:00, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, Apache Kalumet 0.6-incubating release has been voted by the Kalumet podling PMC. I forward the release to the Incubator for final vote. Please find the RELEASE NOTES and staging repository in the original message. Thanks, Regards JB Original Message Subject: [VOTE] Apache Kalumet 0.6-incubating release (3rd try) Date: Thu, 05 Sep 2013 13:30:42 +0200 From: Jean-Baptiste Onofré j...@nanthrax.net Reply-To: kalumet-...@incubator.apache.org To: kalumet-...@incubator.apache.org Hi all, The first release of Kalumet (0.6-incubating) is available. Please take a look on the artifacts (especially the distribution archives), review the documentation and make a try. Release Notes: http://svn.apache.org/repos/asf/incubator/kalumet/tags/kalumet-0.6-incubating/RELEASE-NOTES Staging repository: https://repository.apache.org/content/repositories/orgapachekalumet-013/ Where is the KEYS file? The URL should be included in all votes so reviewers can check the sigs. The vote e-mail should also include the SCM co-ordinates (SVN URL+revision or GIT URL+hash). This is so the source archive contents can be checked against it. Also, the Nexus URLs are temporary (and not unique), so the hashes of the source archives should be included in the vote e-mail. Otherwise there is not way to tie the vote e-mail to the artifacts that are being voted on. Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Do not approve the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- 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 - 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 - 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 (revised proposal)
+1 (binding) Ate On 09/30/2013 09:27 PM, Dave wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. The original proposal has been revised to name Dave Johnson as the Champion and to bring Jim Jagielski back in as a Mentor and to add John Lewis Mcgibbney as a Mentor. I also add some text to the Initial Committers section and a new Interested Contributors section to list those who have expressed interest in contributing. Here is a link to the revised 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 large scale production deployments at major global companies in the media, retail,
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 8:59 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: At Wicket we didn't bother to pick bylaws and from what I have seen in other communities we are better for it. A huge +1 to that! Apache Bigtop falls into the very same category -- we'll get real bylaws when we really need them (hopefully never ;-)). Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, Thanks for the feedback, it's interesting to see that some project don't have bylaws. The whole reason this come about is because it's unclear what voting rules are the default when voting someone in as committer. See [1] (consensus) and [2] (majority). If -1 is a veto or not is sort of important thing to know, and which voting system is used actually changes how people vote. To solve any potential disputes bylaws are perhaps not required but the project at least needs to reach consensus on what voting system should be used. Just before or after graduation would be a good time to do this IMO. After looking at other project bylaws I also realised that we were missing/not discussed a few other reasonably important things like the term of the chair. Perhaps the option of having a boilerplate set of bylaws (taken from an existing project ) could be the default on graduation and then each project make their own by voting to modify them? Thanks, Justin 1. http://community.apache.org/newcommitter.html 2. http://www.apache.org/foundation/voting.html
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
So Apache Merlin sounds good to me. Any objections? On 25 September 2013 23:47, Christian Grobmeier grobme...@gmail.com wrote: Nechtan sounds cool also. Please note, in the german wikipedia its translated with The tremendousness. This is not noted on the english wikipedia. After reading wikipedia I am still not sure what Nechtan stands for. But I like its sound. I just found Sirona, goddess of healing. Because monitoring is identifying the sickness before its getting worse. However, Sirona is used by companies related to healing (aka dental works). What I found interesting is this page claims Merlin being a god: http://wicca.com/celtic/wicca/celtic.htm of protecting, counseling, crystal reading and so. A few projects use Merlin, but all are very small ant not related to monitoring. There is a project management software called marlin: http://www.projectwizards.net/de/merlin/ I believe we currently have: Apache Leitstand Apache Nechtan Apache Merlin Apache Sirona Apache Heimdall Apache Dagr Cheers On 25 Sep 2013, at 15:03, Stephen Connolly wrote: Why not try Celtic mythology I was thinking Apache Nechtan due to the association with access to knowledge and floods... but heck I am not good on my Irish mythology and the Norse ones always sounded way cooler On 25 September 2013 13:23, Christian Grobmeier grobme...@gmail.com wrote: I also see thor is being used by infra: status.apache.org (mentioning, because it has been proposed as name too). However, it's not so bad. I actually mixed up Baldur with Heimdall, who is the actual protector of Bifröst. Baldur was more known because he was able to return from Hel (sounds like a good name for a server ;-) A quick crosscheck told me Heimdall is not used that often. For those who were concerned about using nordic godnames: Heimdall was named as the father of all humans. He was also known for his horn Gjallarhorn which he blew when danger appeared. Most notable he blew that horn when Ragnarökr (the end of our time and the fall of the gods) starts. I imagine the sound of a horn when critical notification of the tool happens ;-) Another idea i just had was Dagr. It old norsk for Day. In old myths Dagr is the son of night and he rides his horse Skinfaxi through heaven. The crest of the horse lights the earth with golden shimmer. I imagine Apache Dagr to shed light on the dark corners of our applications. Heck, when I was young i read a lot about northern mythology. Its so poetic. I should spend some time to read again. On 25 Sep 2013, at 10:19, Daniel Gruno wrote: On 09/25/2013 09:21 AM, Tammo van Lessen wrote: Baldr is fine with me, my only concern is the similarity to Apache Buildr. Just a heads up from infra; baldr.apache.org is already very much a thing, and has been for more than five years. If it can be avoided, we'd really appreciate it if we can keep the name Baldr for our infrastructure. With regards, Daniel. Tammo Am 25.09.2013 01:18 schrieb Olivier Lamy ol...@apache.org: 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.htmlhttp://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
Re: Apache project bylaws
Martijn Dashorst wrote: On Tue, Oct 1, 2013 at 5:28 PM, Ross Gardler rgard...@opendirective.com wrote: +1 to Marvin's I hope that most projects won't bother although there needs to be something a little more than a blank piece of paper. The best approach, IMHO, is to simply make it official that the project adopts the same byelaws as project x, y or z. Pick an established project that has a minimal set of stable byelaws and go on from there. Some projects like to refer to the original project pages, others make a local copy. Both approaches have their advantages. At Wicket we didn't bother to pick bylaws and from what I have seen in other communities we are better for it. Graduation from the incubator is a testament that the community acts as a meritocracy, and the bylaws of the foundation should be good for all graduated projects. As a community I think that Wicket developers never even bothered to look at the bylaws and just follow the established processes and guidances that trickle down from board@. Looking at httpd, they don't have explicit bylaws either–my google fu did not unearth any document at httpd.apache.org that constitutes bylaws. Many project call them guidelines. http://httpd.apache.org/dev/guidelines.html -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 3:34 PM, Justin Mclean justinmcl...@gmail.com wrote: The whole reason this come about is because it's unclear what voting rules are the default when voting someone in as committer. See [1] (consensus) and [2] (majority). If -1 is a veto or not is sort of important thing to know, and which voting system is used actually changes how people vote. The default at Apache is that committers and PMC members are added by consensus. In nearly every project code changes are also by consensus while releases require 3 +1 votes from PMC members and more +1 votes than -1 votes. Projects that diverge from these should perhaps document that somewhere, but projects that conform to these probably don't need to. I see no discrepancy between the documents you cite. The first says that committer votes are by consensus, the second says that procedural votes are by majority, but doesn't define procedural and there's no implication that it includes committer votes. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, I see no discrepancy between the documents you cite. The first says that committer votes are by consensus, the second says that procedural votes are by majority, but doesn't define procedural and there's no implication that it includes committer votes. There was conversation on members@ in the last couple of days (which I'm unable to view) that came to the opposite conclusion, so there's some confusion/differing opinion on the matter. Context is that I was under the assumption that consensus was required to vote a committer in, other PMC members thought otherwise or were unsure. On looking into it, I found it does vary from project to project and that it didn't seem to be defined clearly anywhere if your project doesn't have bylaws/guidelines. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? Doug On Oct 1, 2013 6:06 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I see no discrepancy between the documents you cite. The first says that committer votes are by consensus, the second says that procedural votes are by majority, but doesn't define procedural and there's no implication that it includes committer votes. There was conversation on members@ in the last couple of days (which I'm unable to view) that came to the opposite conclusion, so there's some confusion/differing opinion on the matter. Context is that I was under the assumption that consensus was required to vote a committer in, other PMC members thought otherwise or were unsure. On looking into it, I found it does vary from project to project and that it didn't seem to be defined clearly anywhere if your project doesn't have bylaws/guidelines. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? I was informed by a member on Flex private and here [1] which you already responded to. Thanks, Justin 1. http://markmail.org/thread/chfagblj72cv7zrt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Lots of people on this list are also on members@, and, so far, none have objected to my statements. If this continues, it would indicate a lack of controversy. Doug On Oct 1, 2013 7:36 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? I was informed by a member on Flex private and here [1] which you already responded to. Thanks, Justin 1. http://markmail.org/thread/chfagblj72cv7zrt - 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 (revised proposal)
On Mon, Sep 30, 2013 at 12:27 PM, Dave snoopd...@gmail.com wrote: I would like to call for a new vote on Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. The original proposal has been revised to name Dave Johnson as the Champion and to bring Jim Jagielski back in as a Mentor and to add John Lewis Mcgibbney as a Mentor. I also add some text to the Initial Committers section and a new Interested Contributors section to list those who have expressed interest in contributing. Here is a link to the revised 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 large
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
+1, sounds like the logo idea will be easy ;) Le 2 oct. 2013 01:01, Olivier Lamy ol...@apache.org a écrit : So Apache Merlin sounds good to me. Any objections? On 25 September 2013 23:47, Christian Grobmeier grobme...@gmail.com wrote: Nechtan sounds cool also. Please note, in the german wikipedia its translated with The tremendousness. This is not noted on the english wikipedia. After reading wikipedia I am still not sure what Nechtan stands for. But I like its sound. I just found Sirona, goddess of healing. Because monitoring is identifying the sickness before its getting worse. However, Sirona is used by companies related to healing (aka dental works). What I found interesting is this page claims Merlin being a god: http://wicca.com/celtic/wicca/celtic.htm of protecting, counseling, crystal reading and so. A few projects use Merlin, but all are very small ant not related to monitoring. There is a project management software called marlin: http://www.projectwizards.net/de/merlin/ I believe we currently have: Apache Leitstand Apache Nechtan Apache Merlin Apache Sirona Apache Heimdall Apache Dagr Cheers On 25 Sep 2013, at 15:03, Stephen Connolly wrote: Why not try Celtic mythology I was thinking Apache Nechtan due to the association with access to knowledge and floods... but heck I am not good on my Irish mythology and the Norse ones always sounded way cooler On 25 September 2013 13:23, Christian Grobmeier grobme...@gmail.com wrote: I also see thor is being used by infra: status.apache.org (mentioning, because it has been proposed as name too). However, it's not so bad. I actually mixed up Baldur with Heimdall, who is the actual protector of Bifröst. Baldur was more known because he was able to return from Hel (sounds like a good name for a server ;-) A quick crosscheck told me Heimdall is not used that often. For those who were concerned about using nordic godnames: Heimdall was named as the father of all humans. He was also known for his horn Gjallarhorn which he blew when danger appeared. Most notable he blew that horn when Ragnarökr (the end of our time and the fall of the gods) starts. I imagine the sound of a horn when critical notification of the tool happens ;-) Another idea i just had was Dagr. It old norsk for Day. In old myths Dagr is the son of night and he rides his horse Skinfaxi through heaven. The crest of the horse lights the earth with golden shimmer. I imagine Apache Dagr to shed light on the dark corners of our applications. Heck, when I was young i read a lot about northern mythology. Its so poetic. I should spend some time to read again. On 25 Sep 2013, at 10:19, Daniel Gruno wrote: On 09/25/2013 09:21 AM, Tammo van Lessen wrote: Baldr is fine with me, my only concern is the similarity to Apache Buildr. Just a heads up from infra; baldr.apache.org is already very much a thing, and has been for more than five years. If it can be avoided, we'd really appreciate it if we can keep the name Baldr for our infrastructure. With regards, Daniel. Tammo Am 25.09.2013 01:18 schrieb Olivier Lamy ol...@apache.org: 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 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
Shepherd assignments October 2013
Greets, Please welcome new shepherds Andrei Savu and Raphael Bircher! We look forward to the fresh perspectives you bring. Here are assignments for our October report, which have also been posted on the wiki page. https://wiki.apache.org/incubator/October2013 Raphael Bircher Olingo Alan Cabrera Celix Alan Cabrera VXQuery Dave Fisher DeviceMap Dave Fisher Spark Matt Franklin ODF Toolkit Matt Franklin Sentry Ross Gardler Ripple Suresh Marru Samza Suresh Marru MetaModel Andrei Savu Marmotta Roman Shaposhnik Helix Roman Shaposhnik Stratos Four podlings are not being assigned shepherds this month: Chukwa (graduating) jclouds (graduating) Storm (just starting out) Tashi (in the process of retiring) Please file your reports via the wiki by the end of this coming weekend. I plan to email a compendium to general@incubator on Monday to allow time for comment before the Incubator report is delivered to the Board on Wednesday. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
