Re: Apache project bylaws
On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui aha...@adobe.com wrote: I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. I'm sure I haven't nailed it so feel free to comment. And I'm not quite sure how to do a table in mdtext. I'm off to sleep so I'll respond several hours from now. Thanks for reading... -Alex --- Updated voting.mdtext -- Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. At the Apache Software Foundation, two decisions must be made by a vote held on a project's mailing list. The two decisions are: 1. Code modifications, 1. Package releases Other decisions are commonly made via votes as well, but a project may draft by-laws or guidelines that describe variations to the voting processes described below. If a project does not draft by-laws or guidelines, it is assumed that any votes held to make any of the decisions listed below follow the processes described below. Many projects make the following decisions via voting: 1. Approving a new committer 1. Approving a new PMC member 1. Approving a new PMC Chair 1. Removing a committer 1. Removing a PMC member 1. Approving by-laws or guidelines or changes to by-laws or guidelines Many project by-laws and guidelines describe other decisions made via voting. Use of [lazy consensus](#LazyConsensus) is recommended for as many other decisions as possible. Here is a table of the default voting processes: table trthAction/ththApproval/ththDuration/th/tr trtdCode Modification/tdtd[lazy consensus](#LazyConsensus)/tdtd72 hours/td/tr trtdApprove Release/tdtd[majority](#Majority)/tdtd72 hours/td/tr trtdApprove New Committer/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr trtdApprove New PMC Member/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr trtdApprove New PMC Chair/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr trtdRemove Committer/tdtd[consensus-but-one](#ConsensusButOne)/tdtd72 hours/td/tr trtdRemove PMC Member/tdtd[consensus-but-one](#ConsensusButOne)/tdtd72 hours/td/tr trtdApprove/Change By-laws/Guidelines/tdtd[majority](#Majority)/tdtd72 hours/td/tr trtdApprove Donation/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr # Binding Votes # Who is permitted to vote is, to some extent, a project-specific thing. However, the default rule is that for Code Modification, any committer's veto counts, but for all other decisions only PMC members have binding votes, and all others have their votes considered of an indicative or advisory nature only. By default, only active PMC members may cast votes. Project's can define their own definition of active, but the default definition is whether that member has sent an email on any Apache mailing list, made a change to any asset under Apache version control, or voted on any vote thread. This low bar is intended to cover mature projects that don't do much other than file quarterly reports. # Implications of Voting # In some cases and communities, the exercise of a vote carries some responsibilities that may not be immediately obvious. For example, in some cases a favourable vote carries the implied message 'I approve **and** I'm willing to help.' Also, an unfavourable vote may imply that 'I disapprove, but I have an alternative and will help with that alternative.' The tacit implications of voting should be spelt out in the community's guidelines.
Re: [VOTE] BatchEE as an incubated project
And here is my +1 I'll prepare the result mail. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/1 Tammo van Lessen tvanles...@gmail.com +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
[RESULT][VOTE] BatchEE as an incubated project
The vote for BatchEE to become an incubated project has passed with 9 +1 binding votes, 3 +1 non-binding votes, and no -1 or 0 votes. *Binding +1 Votes:* Olivier Lamy Bertrand Delacretaz Jean-Baptiste Onofré Christian Müller Matt Benson Mark Struberg Matthias Wessendorf Gerhard Petracek Tammo van Lessen *Non-Binding +1 Votes:* Rahul Sharma Jean-Louis Monteiro Romain Manni-Bucau Congrats to all involved! Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
Re: [ANNOUNCE] Christian Müller joins the IPMC
Thanks for the warm welcome. Because I'm a newbie here, be aware of stupid questions... ;-) Best, Christian Am 03.10.2013 08:02 schrieb Romain Manni-Bucau rmannibu...@gmail.com: Congrats! *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/3 Jean-Louis MONTEIRO jeano...@gmail.com Congrats Christian. Jean Louis Le 3 oct. 2013 01:20, Marvin Humphrey mar...@rectangular.com a écrit : Apache Member and Apache Camel PMC Chair Christian Müller has joined the Incubator PMC. Welcome! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANNOUNCE] Christian Müller joins the IPMC
Congrats! :) On Thu, Oct 3, 2013 at 11:49 AM, Christian Müller christian.muel...@gmail.com wrote: Thanks for the warm welcome. Because I'm a newbie here, be aware of stupid questions... ;-) Best, Christian Am 03.10.2013 08:02 schrieb Romain Manni-Bucau rmannibu...@gmail.com: Congrats! *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/3 Jean-Louis MONTEIRO jeano...@gmail.com Congrats Christian. Jean Louis Le 3 oct. 2013 01:20, Marvin Humphrey mar...@rectangular.com a écrit : Apache Member and Apache Camel PMC Chair Christian Müller has joined the Incubator PMC. Welcome! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [VOTE] Retire the Tashi podling
+1 On 3 October 2013 09:45, Marvin Humphrey mar...@rectangular.com wrote: Greets, As discussed previously on general@incubator[1], the Tashi community has voted to retire from the Incubator. Following the retirement guide[2], it is now time for an IPMC vote ratifying their decision. [ ] +1 Retire the Tashi podling [ ] +0 Neither here nor there [ ] -1 Do not retire the podling because ... This vote will remain open for at least the next 72 hours. Here is my +1. Marvin Humphrey [1] http://s.apache.org/G1S [2] http://incubator.apache.org/guides/retirement.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
Sounds good for me too. On 2 October 2013 18:19, Mark Struberg strub...@yahoo.de wrote: -1 for Merlin. Just too widely used :( There are 10++ pages of trademarks in all fields in trademarkia, many of them in the software area +1 for Sirona as it has a nice meaning and it seems to not be used for any software related product so far. LieGrue, strub - Original Message - From: Jean-Baptiste Onofré j...@nanthrax.net To: general@incubator.apache.org Cc: Sent: Wednesday, 2 October 2013, 8:46 Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring +1 Regards JB On 10/02/2013 01:01 AM, Olivier Lamy wrote: 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.
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
works for me too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/3 Olivier Lamy ol...@apache.org Sounds good for me too. On 2 October 2013 18:19, Mark Struberg strub...@yahoo.de wrote: -1 for Merlin. Just too widely used :( There are 10++ pages of trademarks in all fields in trademarkia, many of them in the software area +1 for Sirona as it has a nice meaning and it seems to not be used for any software related product so far. LieGrue, strub - Original Message - From: Jean-Baptiste Onofré j...@nanthrax.net To: general@incubator.apache.org Cc: Sent: Wednesday, 2 October 2013, 8:46 Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring +1 Regards JB On 10/02/2013 01:01 AM, Olivier Lamy wrote: 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
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
No problem, that sounds good as well. JLouis 2013/10/3 Romain Manni-Bucau rmannibu...@gmail.com works for me too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/3 Olivier Lamy ol...@apache.org Sounds good for me too. On 2 October 2013 18:19, Mark Struberg strub...@yahoo.de wrote: -1 for Merlin. Just too widely used :( There are 10++ pages of trademarks in all fields in trademarkia, many of them in the software area +1 for Sirona as it has a nice meaning and it seems to not be used for any software related product so far. LieGrue, strub - Original Message - From: Jean-Baptiste Onofré j...@nanthrax.net To: general@incubator.apache.org Cc: Sent: Wednesday, 2 October 2013, 8:46 Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring +1 Regards JB On 10/02/2013 01:01 AM, Olivier Lamy wrote: 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
[RESULT][VOTE] Release Apache Marmotta 3.1.0-incubating
Dear all, thanks for your support! The 72 hours have now passed and we have 8 positive votes, of which 3 are binding and 5 are non-binding. We now have the required number of positive binding votes and will therefore proceed with the release. The remark by sebb has been added as an issue for the next release (MARMOTTA-327). Greetings, Sebastian 2013/10/2 Olivier Lamy ol...@apache.org +1 sources build fine. -- Olivier On Sep 30, 2013 8:17 PM, 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 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 *
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
It works for me. Regards JB On 10/02/2013 10:19 AM, Mark Struberg wrote: -1 for Merlin. Just too widely used :( There are 10++ pages of trademarks in all fields in trademarkia, many of them in the software area +1 for Sirona as it has a nice meaning and it seems to not be used for any software related product so far. LieGrue, strub - Original Message - From: Jean-Baptiste Onofré j...@nanthrax.net To: general@incubator.apache.org Cc: Sent: Wednesday, 2 October 2013, 8:46 Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring +1 Regards JB On 10/02/2013 01:01 AM, Olivier Lamy wrote: 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
Re: Apache project bylaws
On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting of the diff is messed up because of line wrapping by your email client. Please take the time to present such a costly-to-review patch in a way which accommodates your potential reviewers. I suggest posting a link to a persistent paste created using https://paste.apache.org. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire the Tashi podling
+1 On Wed, Oct 2, 2013 at 7:45 PM, Marvin Humphrey mar...@rectangular.comwrote: Greets, As discussed previously on general@incubator[1], the Tashi community has voted to retire from the Incubator. Following the retirement guide[2], it is now time for an IPMC vote ratifying their decision. [ ] +1 Retire the Tashi podling [ ] +0 Neither here nor there [ ] -1 Do not retire the podling because ... This vote will remain open for at least the next 72 hours. Here is my +1. Marvin Humphrey [1] http://s.apache.org/G1S [2] http://incubator.apache.org/guides/retirement.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire the Tashi podling
+1 Regards, Alan On Oct 2, 2013, at 4:45 PM, Marvin Humphrey mar...@rectangular.com wrote: [ ] +1 Retire the Tashi podling [ ] +0 Neither here nor there [ ] -1 Do not retire the podling because ...
Re: [VOTE] Retire the Tashi podling
+1 LieGrue, strub From: Alan D. Cabrera l...@toolazydogs.com To: general@incubator.apache.org Sent: Thursday, 3 October 2013, 16:34 Subject: Re: [VOTE] Retire the Tashi podling +1 Regards, Alan On Oct 2, 2013, at 4:45 PM, Marvin Humphrey mar...@rectangular.com wrote: [ ] +1 Retire the Tashi podling [ ] +0 Neither here nor there [ ] -1 Do not retire the podling because ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/3/13 6:23 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be just words and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were right about the old version are retained and whether the things that were wrong have been removed, and new content appears to be right. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting of the diff is messed up because of line wrapping by your email client. Please take the time to present such a costly-to-review patch in a way which accommodates your potential reviewers. I suggest posting a link to a persistent paste created using https://paste.apache.org. And with the above disclaimer, instead of using paste.a.o, I propose to revise this document using CMS and/or SVN. That way we can track changes, and I can use color and
Re: Apache project bylaws
Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. On Oct 3, 2013, at 11:40 AM, Alex Harui aha...@adobe.com wrote: On 10/3/13 6:23 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be just words and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were right about the old version are retained and whether the things that were wrong have been removed, and new content appears to be right. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting of the diff is messed up because of line wrapping by your email client. Please take the time to present such a costly-to-review patch in a way which
Re: [VOTE] Retire the Tashi podling
On Wed, Oct 2, 2013 at 4:45 PM, Marvin Humphrey mar...@rectangular.com wrote: Greets, As discussed previously on general@incubator[1], the Tashi community has voted to retire from the Incubator. Following the retirement guide[2], it is now time for an IPMC vote ratifying their decision. [ ] +1 Retire the Tashi podling [ ] +0 Neither here nor there [ ] -1 Do not retire the podling because ... +1 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
For committership, that is typical. Most PMCs allow a veto for adding new members to the PMC. On Thu, Oct 3, 2013 at 10:48 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. On Oct 3, 2013, at 11:40 AM, Alex Harui aha...@adobe.com wrote: On 10/3/13 6:23 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be just words and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were right about the old version are retained and whether the things that were wrong have been removed, and new content appears to be right. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting
[RESULTS] Usergrid BaaS Stack for Apache Incubator (revised proposal)
I am officially closing the vote. We have 11 binding +1 votes, 4 non-binding votes and no -1 notes. Usergrid is now officially part of the Apache Incubator. Thanks to everybody who helped put together the proposal, those who joined the discussion, those who voted and the Usergrid community. +1 binding votes Afkham Azeez Alan D. Cabrera Alex Karasulu Ate Douma Bertrand Delacretaz Chip Childers David Nalley Henry Saputra Jim Jagielski Luciano Resende Marvin Humphrey +1 non-binding Larry McCay Lewis John Mcgibbney Lieven Govaerts Raminder Singh Totals 11 binding +1 votes 4 non-binding +1 votes 0 -1 votes Thanks, Dave PS. this also happens to be the 2nd anniversary of the day that Usergrid was released on Github. Happy Birthday Usergrid!
Re: Apache project bylaws
The definitions are in a glossary somewhere, the more we denormalize the locations of our common understandings the harder it will be to maintain sanity over discussions. Projects don't need to be encouraged to write their own bylaws, most don't bother and that's proper. We don't need to spell every possible decision making process out in detail because they should have experienced the normal processes during incubation under competent mentorship. In other words I agree with Marvin that widespread changes to documents that have been widely referenced are not a good idea, no matter what the board happens to think today. Just clarify the actual issues before us, e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, so there's surely room for improvement. On Oct 3, 2013, at 12:44 PM, Alex Harui aha...@adobe.com wrote: On 10/3/13 8:48 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. Hmm. Maybe I'm reaching too far, but my hope was to put in this document a definition of consensus and a set of defaults for by-laws so that other new projects don't have as much if any work to do in defining their project-specific by-laws. -Alex - 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 10/3/13 8:48 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. Hmm. Maybe I'm reaching too far, but my hope was to put in this document a definition of consensus and a set of defaults for by-laws so that other new projects don't have as much if any work to do in defining their project-specific by-laws. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULTS] Usergrid BaaS Stack for Apache Incubator (revised proposal)
Welcome to ASF incubator Usergrid =) - Henry On Thu, Oct 3, 2013 at 9:49 AM, Dave snoopd...@gmail.com wrote: I am officially closing the vote. We have 11 binding +1 votes, 4 non-binding votes and no -1 notes. Usergrid is now officially part of the Apache Incubator. Thanks to everybody who helped put together the proposal, those who joined the discussion, those who voted and the Usergrid community. +1 binding votes Afkham Azeez Alan D. Cabrera Alex Karasulu Ate Douma Bertrand Delacretaz Chip Childers David Nalley Henry Saputra Jim Jagielski Luciano Resende Marvin Humphrey +1 non-binding Larry McCay Lewis John Mcgibbney Lieven Govaerts Raminder Singh Totals 11 binding +1 votes 4 non-binding +1 votes 0 -1 votes Thanks, Dave PS. this also happens to be the 2nd anniversary of the day that Usergrid was released on Github. Happy Birthday Usergrid! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/3/13 9:51 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: The definitions are in a glossary somewhere, the more we denormalize the locations of our common understandings the harder it will be to maintain sanity over discussions. OK, found the glossary. I will try to leverage it more in the next revision. It will probably need to have consensus-but-one added to it. Projects don't need to be encouraged to write their own bylaws, most don't bother and that's proper. Unfortunately, new TLPs are all copying the same board resolution which dictates that we need to write bylaws. That's independent of this thread, but something that I also suggested changing. We don't need to spell every possible decision making process out in detail because they should have experienced the normal processes during incubation under competent mentorship. Well, maybe we got lucky but we got through incubation without any major conflicts about who should be added and didn't have to deal with removing anyone. I think there should be defaults for handling removals in the voting document. In other words I agree with Marvin that widespread changes to documents that have been widely referenced are not a good idea, no matter what the board happens to think today. Just clarify the actual issues before us, e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, so there's surely room for improvement. OK, I'll try again tonight. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire the Tashi podling
On Wed, Oct 02, 2013 at 04:45:31PM -0700, Marvin Humphrey wrote: Greets, As discussed previously on general@incubator[1], the Tashi community has voted to retire from the Incubator. Following the retirement guide[2], it is now time for an IPMC vote ratifying their decision. [ ] +1 Retire the Tashi podling [ ] +0 Neither here nor there [ ] -1 Do not retire the podling because ... +1 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
