Re: [VOTE] Accept Aurora for Apache Incubation
On Thu, Sep 26, 2013 at 6:08 PM, Dave Lester d...@ischool.berkeley.edu wrote: ...I'd like to call a vote for Aurora to become an incubated project... +1 -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] BatchEE as an incubated project
+1 (binding) -- Olivier On Sep 30, 2013 2:53 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open source projects. Initial committer of the project thinks that ASF has great place that provides wider colloboration and support of the open source project and it respects
Re: [VOTE] BatchEE as an incubated project
On Mon, Sep 30, 2013 at 6:52 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: ...I'd like to call a vote for BatchEE to become an incubated project... +1 -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] BatchEE as an incubated project
+1 regards Rahul On Mon, Sep 30, 2013 at 1:22 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Sep 30, 2013 at 6:52 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: ...I'd like to call a vote for BatchEE to become an incubated project... +1 -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] BatchEE as an incubated project
+1 (binding) Regards JB On 09/30/2013 11:06 AM, Rahul Sharma wrote: +1 regards Rahul On Mon, Sep 30, 2013 at 1:22 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Sep 30, 2013 at 6:52 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: ...I'd like to call a vote for BatchEE to become an incubated project... +1 -Bertrand - 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: [VOTE] BatchEE as an incubated project
+1 Best, Christian Christian Müller - Software Integration Specialist Apache Camel committer: https://camel.apache.org/team V.P. Apache Camel: https://www.apache.org/foundation/ Apache Member: https://www.apache.org/foundation/members.html https://www.linkedin.com/pub/christian-mueller/11/551/642 On Mon, Sep 30, 2013 at 6:52 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An
[VOTE] Release Apache Marmotta 3.1.0-incubating
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 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 different set of prefixes in the query evaluation than the showed at the user interface * [MARMOTTA-231] - Admin Interface: changing list values does not work * [MARMOTTA-232] - Reasoner does not add all justifications * [MARMOTTA-234] - Loading webjars resources doesn't work
Re: [VOTE] BatchEE as an incubated project
+1 (binding) Matt On Sun, Sep 29, 2013 at 11:52 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open source projects. Initial committer of the project thinks that ASF has great place that provides wider colloboration and support of the open source project and it respects
Re: [VOTE] BatchEE as an incubated project
+1 Jean-Louis 2013/9/30 Matt Benson gudnabr...@gmail.com +1 (binding) Matt On Sun, Sep 29, 2013 at 11:52 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is
Re: [VOTE] BatchEE as an incubated project
+1 (binding) LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 30 September 2013, 6:52 Subject: [VOTE] BatchEE as an incubated project Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open
Re: [VOTE] BatchEE as an incubated project
+1 (binding) On Monday, September 30, 2013, Mark Struberg wrote: +1 (binding) LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 30 September 2013, 6:52 Subject: [VOTE] BatchEE as an incubated project Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessa- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.orgjavascript:; For additional commands, e-mail: general-h...@incubator.apache.orgjavascript:; -- Sent from Gmail Mobile
Re: [VOTE] BatchEE as an incubated project
+1 regards, gerhard 2013/9/30 Matthias Wessendorf mat...@apache.org +1 (binding) On Monday, September 30, 2013, Mark Struberg wrote: +1 (binding) LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 30 September 2013, 6:52 Subject: [VOTE] BatchEE as an incubated project Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessa- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Sent from Gmail Mobile
Re: Voting in Committers
On Sun, Sep 29, 2013 at 7:39 AM, Alex Harui aha...@adobe.com wrote: The answer I got on members@ is that [1] is not a policy document and therefore a vote as to whether to make someone a committer defaults to majority rules unless the TLP has voted otherwise, and a -1 vote is not a veto unless the TLP has voted otherwise. On the contrary, I believe the default at Apache is that committer and PMC votes are by consensus, that a -1 is a veto. The rationale is that committers and PMCs must regularly reach consensus on code changes, so adding folks without consensus creates projects that cannot function. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
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, telecommunication and government spaces. The Apache Software
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
+1 (binding) Good luck guys - Henry 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
Re: [VOTE] BatchEE as an incubated project
+1 (binding) Best, Tammo On Mon, Sep 30, 2013 at 7:24 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2013/9/30 Matthias Wessendorf mat...@apache.org +1 (binding) On Monday, September 30, 2013, Mark Struberg wrote: +1 (binding) LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 30 September 2013, 6:52 Subject: [VOTE] BatchEE as an incubated project Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessa- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Sent from Gmail Mobile -- Tammo van Lessen - http://www.taval.de
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. +1 (binding) Good luck! Marvin Humphrey - 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 (non-binding) On Sat, Sep 28, 2013 at 9:39 AM, Andy Konwinski andykonwin...@gmail.comwrote: +1 On Sep 26, 2013 11: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
Apache project bylaws
Hi, Looks like one of the things that fell between the cracks when Apache Flex become a top level project was drafting up and accepting a set of bylaws. I see nothing about bylaws on the incubator website, including here [1] where I would expect it to be. Should the process on this page be updated? Are bylaws optional or should they be a required part of graduation? Thanks, Justin 1. http://incubator.apache.org/guides/graduation.html PS We're in the process of putting our bylaws together here. Still in very early draft form, suggestions and/or advice is welcome. https://cwiki.apache.org/confluence/display/FLEX/Draft+Bylaws - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Justin Mclean wrote: Hi, Looks like one of the things that fell between the cracks when Apache Flex become a top level project was drafting up and accepting a set of bylaws. I see nothing about bylaws on the incubator website, including here [1] where I would expect it to be. Should the process on this page be updated? Are bylaws optional or should they be a required part of graduation? 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 ... Review/adopt/adapt the bylaws of other projects that have gone before you. I reckon that it is beyond the Incubator. Yes the docs should mention that future task. -David Thanks, Justin 1. http://incubator.apache.org/guides/graduation.html PS We're in the process of putting our bylaws together here. Still in very early draft form, suggestions and/or advice is welcome. https://cwiki.apache.org/confluence/display/FLEX/Draft+Bylaws - 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 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
Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
+1 (binding) Azeez On Tue, Oct 1, 2013 at 12:57 AM, 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
