Re: Vote on personal matters: majority vote vs consensus
On Mon, Mar 25, 2013 at 7:52 AM, ant elder ant.el...@gmail.com wrote: Your second suggestion sounds like the thing to do to me - separating IPMC-ship and Mentor-ship - that would solve several of the problems we've being having including this one, it would open up a much bigger pool of potential mentors, and IPMC'ers would get much more visibility of people as they work here which should make the PMC voting easier. Ok some people sound like they like this suggestion, and some others have expressed concern about the lack of a binding vote. I'd like to try this, perhaps as a sort of experiment like we've done for other changes in the past. I'll post a more articulate proposal in a new thread but doesn't anyone else have any feelings about this either way? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Creating announce@ lists by default
On Wed, Mar 27, 2013 at 2:14 AM, Marvin Humphrey mar...@rectangular.com wrote: ...As to whether such lists should be encouraged for new podlings (probably by putting a stub in the proposal template alongside the other lists), I can't say that I have a strong opinion IIUC Noah's proposal goes further and suggests creating an announce@ list by default for every new podling. I'm against that - suggesting that podlings create it is fine (as long as we indicate that there's announce@a.o. which is in general sufficient) but the default setup of a podling should be minimalistic, as each podling is different. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013 at 8:35 AM, ant elder ant.el...@gmail.com wrote: On Mon, Mar 25, 2013 at 7:52 AM, ant elder ant.el...@gmail.com wrote: ...Your second suggestion sounds like the thing to do to me - separating IPMC-ship and Mentor-ship... ...I'd like to try this, perhaps as a sort of experiment like we've done for other changes in the past. I'll post a more articulate proposal in a new thread but doesn't anyone else have any feelings about this either way?... As I said before I'm currently against having mentors who are not Incubator PMC members, because it creates more options that require more work when checking things and because mentors need to have binding votes. But as I said elsewhere, only idiots never change their minds...let's see your proposal. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Created] (PODLINGNAMESEARCH-31) Establish whether Apache DeltaSpike is a suitable name
John D. Ament created PODLINGNAMESEARCH-31: -- Summary: Establish whether Apache DeltaSpike is a suitable name Key: PODLINGNAMESEARCH-31 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: John D. Ament DeltaSpike is a portmanteau of Delta (for change) and Spike (for 'an abrupt sharp increase'). From the ASF perspective, it is a library of reusable CDI extensions and components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
Hi, As I said before I'm currently against having mentors who are not Incubator PMC members, As an aside it seems (and please correct me if I'm mistaken) in order to become a IPMC member you first need to be an Apache member (see bottom of [1]).This may exclude people with practical experience of being involved in a podling and making it a top level project who want to help out with other podlings. Of course they can help out in ways that doesn't involve them being a mentor but (IMO) the barrier to entry seems a little high. I also been unable to find any info on the incubator site on shepherds and what's the process to become involved there. If someone could point me in the right direction I'd be grateful. Thanks, Justin 1. http://incubator.apache.org/guides/participation.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013 at 11:44 AM, Justin Mclean justinmcl...@gmail.com wrote: ...As an aside it seems (and please correct me if I'm mistaken) in order to become a IPMC member you first need to be an Apache member (see bottom of [1])... you don't - Apache members can become IPMC members just by asking, but others can also be elected as incubator PMC members. We do have some such mentors currently. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013, at 10:44 AM, Justin Mclean wrote: Hi, As I said before I'm currently against having mentors who are not Incubator PMC members, As an aside it seems (and please correct me if I'm mistaken) in order to become a IPMC member you first need to be an Apache member (see bottom of [1]).This may exclude people with practical experience of being involved in a podling and making it a top level project who want to help out with other podlings. Of course they can help out in ways that doesn't involve them being a mentor but (IMO) the barrier to entry seems a little high. I also been unable to find any info on the incubator site on shepherds and what's the process to become involved there. If someone could point me in the right direction I'd be grateful. Shepherding is a new thing, loosely based upon an approach that the board has used for some time. I'm sure it is largely undocumented. I suspect that generally speaking it is incubator PMC members that do shepherding, but if someone reads reports and provides useful analysis, I suspect this will be greatly appreciated. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
I suppose that as chair I ought to be heard from here. I've been off for Passover for a bit. In my view, the IPMC manifests two problems. I'd like to label them as 'operational' and 'decision-making'. This thread is about decision-making, but with some people seeing using terms like 'disfunctional', I think it's important to keep 'function' in context. Operationally, we 'started' 1.3 years ago with an acute problem of under-supervised and/or 'malingering' podlings. Under Jukka's leadership, we made a series of incremental changes that have considerably improved the situation. On the other hand, the recent influx of many new podlings worries me, because 'improved' is not the same as 'fixed'. And I'm not entirely sure that 'fixed' is possible. I'd like to see us find more incremental changes that help further, and I'd like them to scale via some mechanism other than my own personal time. I see this as a reason to put more thought into shepherds and champions. But I don't see this situation as 'disfunctional'. On the decision-making front, recent phenomena have demonstrated to me that this group is not succeeding in applying consensus process to decision making. I could write five paragraphs on what that process is and what it requires, but I'm not inclined to. I support the proposal here to apply majority rules to IPMC membership. When consensus process fails here, we have endless email threads. Many of us find these stressful, time-consuming, and disheartening. Under the proposal at hand, we'd still DISCUSS, and I'd hope that we would all try to be thoughtful and constructive and look for ways to agree. However, after a certain amount of discussion, there would be a vote, and that would be that. If this 'works' -- if people here find that it strikes a good balance between seeking consensus and limiting time and stress, we're good. It might not work. Or it might 'work', but some might feel that this large, diffuse, group, operating by majority rules is either inconsistent with Apache policy or a bad example for the podlings. In which case someone might want to dust off the proposals from 1.3 years ago that offered more or less radical alternatives. I'm personally not ready to go there yet. On Wed, Mar 27, 2013 at 7:03 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Mar 27, 2013 at 11:44 AM, Justin Mclean justinmcl...@gmail.com wrote: ...As an aside it seems (and please correct me if I'm mistaken) in order to become a IPMC member you first need to be an Apache member (see bottom of [1])... you don't - Apache members can become IPMC members just by asking, but others can also be elected as incubator PMC members. We do have some such mentors currently. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (PODLINGNAMESEARCH-31) Establish whether Apache DeltaSpike is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615145#comment-13615145 ] Mark Struberg commented on PODLINGNAMESEARCH-31: Hi! For having all on record. DeltaSpike entered incubation in December 2011. Before we came up with the name 'DeltaSpike' we had about 30 other candidates. We checked the following points back then, and I also checked them once again today: * no existing trademarks: trademarkia and oami.europa.eu shows no registered trademark * no existing software project exists with this name: searched via ohloh, sf.net, google, yahoo * a domain name deltaspike.com is registered to a domain reseller but is apparently not used (screenshot of the page attached) . Thus no problem. * the name is principally trademarkable. No natural name, no real-live object, etc Establish whether Apache DeltaSpike is a suitable name Key: PODLINGNAMESEARCH-31 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: John D. Ament DeltaSpike is a portmanteau of Delta (for change) and Spike (for 'an abrupt sharp increase'). From the ASF perspective, it is a library of reusable CDI extensions and components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Updated] (PODLINGNAMESEARCH-31) Establish whether Apache DeltaSpike is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated PODLINGNAMESEARCH-31: --- Attachment: deltaspike.com Bildschirmfoto 2013-03-27 um 12.58.58.png documentation of the domain deltaspike.com not being in use Establish whether Apache DeltaSpike is a suitable name Key: PODLINGNAMESEARCH-31 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: John D. Ament Attachments: deltaspike.com Bildschirmfoto 2013-03-27 um 12.58.58.png DeltaSpike is a portmanteau of Delta (for change) and Spike (for 'an abrupt sharp increase'). From the ASF perspective, it is a library of reusable CDI extensions and components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Fwd: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top Level Project
FYI, Apache DeltaSpike looking to graduate soon.
-- Forwarded message --
From: Mark Struberg strub...@yahoo.de
Date: Mon, Mar 25, 2013 at 5:35 PM
Subject: [VOTE] Recommending DeltaSpike for Graduation to an Apache Top
Level Project
To: deltaspike-us...@incubator.apache.org
deltaspike-us...@incubator.apache.org, deltaspike
deltaspike-...@incubator.apache.org
Lords and Ladies.
Please find attached the PROPOSAL for graduating DeltaSpike out of the
Incubator and establishing it as TLP.
[+1] yea, all fine and I like it
[+0] no blocker, but I don't care
[-1] nah there's a blocker in there. Abort and re-roll because of ${reason}
The internal VOTE is open for 72h. After that we gonna tally and forward
the VOTE to the IPMC to VOTE about the recommendation. Once this is done,
the board might consider our wish in the upcoming board meeting.
LieGrue,
strub
---
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
Re: [VOTE] Graduate Apache Onami as TLD
+1 (binding) On Tue, Mar 26, 2013 at 8:04 AM, Christian Grobmeier grobme...@gmail.comwrote: Hi all, Apache Onami entered incubation before more than 3 months. Since then the community has proven to be pretty active and healthy. A few releases were made and the status page has been completed: http://incubator.apache.org/projects/onami.html Three new committers were added in the past weeks. SVNSearch shows, there is clearly one guy who is outstanding in his motivation, but others do commit as well: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fonami Mailinglist Archives show the Community is discussing in public: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/ The community consists of new Apache-people and some more experienced Apache-people. I do not see any problem regarding developing the Apache-way. I agree on that regard as additionally to the experienced people in the project also the mentors are moving on with the project which will help in the future in case of any issues if any. Way to go Onami, good work :) A [DISCUSS] thread on general@ showed no concerns. Simone Tripodi has been elected as the new Chair: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/%3CCAPFNckisQo29Ssy6Q-WkKgAZLRa3VW%2B7afLCEbbVy6HsWX_rAg%40mail.gmail.com%3E A resolution has been created and voted on: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/%3CCAPFNckjDujef_G6t1%3DjuTdOvuXsgxWq-%2BGntiOMdFpE%3DgwReDg%40mail.gmail.com%3E The community vote for becoming a TLD was successful too: http://onami-dev.markmail.org/thread/6w2dvrs3bj755kdm We now kindly ask the IPMC to review our findings and vote on the Onami graduation. [ ] +1, yes propose the graduation of Apache Onami to the board [ ] -1, no, don't let Apache Onami graduate, because... Thanks, Christian -- http://www.grobmeier.de https://www.timeandbill.de - 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] Graduate Apache Onami as TLD
On Tue, Mar 26, 2013 at 8:04 AM, Christian Grobmeier grobme...@gmail.com wrote: ...We now kindly ask the IPMC to review our findings and vote on the Onami graduation... +1 -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Onami as TLD
+1 (binding) LieGrue, strub - Original Message - From: Christian Grobmeier grobme...@gmail.com To: general@incubator.apache.org general@incubator.apache.org Cc: Sent: Tuesday, March 26, 2013 8:04 AM Subject: [VOTE] Graduate Apache Onami as TLD Hi all, Apache Onami entered incubation before more than 3 months. Since then the community has proven to be pretty active and healthy. A few releases were made and the status page has been completed: http://incubator.apache.org/projects/onami.html Three new committers were added in the past weeks. SVNSearch shows, there is clearly one guy who is outstanding in his motivation, but others do commit as well: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fonami Mailinglist Archives show the Community is discussing in public: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/ The community consists of new Apache-people and some more experienced Apache-people. I do not see any problem regarding developing the Apache-way. A [DISCUSS] thread on general@ showed no concerns. Simone Tripodi has been elected as the new Chair: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/%3CCAPFNckisQo29Ssy6Q-WkKgAZLRa3VW%2B7afLCEbbVy6HsWX_rAg%40mail.gmail.com%3E A resolution has been created and voted on: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/%3CCAPFNckjDujef_G6t1%3DjuTdOvuXsgxWq-%2BGntiOMdFpE%3DgwReDg%40mail.gmail.com%3E The community vote for becoming a TLD was successful too: http://onami-dev.markmail.org/thread/6w2dvrs3bj755kdm We now kindly ask the IPMC to review our findings and vote on the Onami graduation. [ ] +1, yes propose the graduation of Apache Onami to the board [ ] -1, no, don't let Apache Onami graduate, because... Thanks, Christian -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Onami as TLD
On Mar 26, 2013, at 3:04 AM, Christian Grobmeier wrote: We now kindly ask the IPMC to review our findings and vote on the Onami graduation. [ X ] +1, yes propose the graduation of Apache Onami to the board [ ] -1, no, don't let Apache Onami graduate, because... +1 -- Rich Bowen rbo...@rcbowen.com Shosholoza
Re: Creating announce@ lists by default
Bertrand, yes, I am not sold on the idea of doing it by default. But perhaps sort of advisory, highlighting it as an option, and giving reasons why it might be a good idea for some projects? What would I have to do to add that? If I prepare a patch to the docs, would it be CTR or RTC? On 27 March 2013 08:54, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Mar 27, 2013 at 2:14 AM, Marvin Humphrey mar...@rectangular.com wrote: ...As to whether such lists should be encouraged for new podlings (probably by putting a stub in the proposal template alongside the other lists), I can't say that I have a strong opinion IIUC Noah's proposal goes further and suggests creating an announce@ list by default for every new podling. I'm against that - suggesting that podlings create it is fine (as long as we indicate that there's announce@a.o. which is in general sufficient) but the default setup of a podling should be minimalistic, as each podling is different. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: Creating announce@ lists by default
On Wed, Mar 27, 2013 at 3:45 PM, Noah Slater nsla...@apache.org wrote: Bertrand, yes, I am not sold on the idea of doing it by default. But perhaps sort of advisory, highlighting it as an option, and giving reasons why it might be a good idea for some projects? Yes, sounds good to me if it's just a suggestion. What would I have to do to add that? If I prepare a patch to the docs, would it be CTR or RTC? If if it's just a suggestion I'd say CTR. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013 at 11:55 AM, Benson Margulies bimargul...@gmail.com wrote: Or it might 'work', but some might feel that this large, diffuse, group, operating by majority rules is either inconsistent with Apache policy or a bad example for the podlings. Thats more how i see it. Using consensus instead of majority votes is one of the main things that makes the ASF special, so we should avoid changing from that if we can, for both those reasons you suggest. And there is nothing that needs this changed presently so IMHO its not necessary to change anything. I'd like to see us find more incremental changes that help further Ok, i propose we have an experiment [1] where we try having a mentor or two who are not PMC members. Have some other experienced mentors helping to make sure nothing unfixable can go wrong, and just see how it goes for a while, reporting each month with the status. Maybe it will fail and we'll know not to try that again, but i think and hope it should work ok. If it does work ok then changing to make this more common would avoid a lot of the times were we need to make new not well known people PMC members or have these debates, which solves part of the problem here. If that works then there are some further small incremental changes we can make which will also help with reasons for people needing to join the PMC, and those will help with the PMC size and disparity issues. Wouldn't a small experiment like this be worth trying before we drop something as fundamental as using consensus? ...ant [1] We tried a similar experiment with the change back to allow poddlings to vote for their own committers again which was similarly controversial before it was tried - http://mail-archives.apache.org/mod_mbox/incubator-general/201008.mbox/%3C974721.3581.qm%40web54401.mail.re2.yahoo.com%3E - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
The incubator is currently of a scale that means it can no longer operate as a standard consensus driven PMC. It is not that much smaller than the TLPs part of the foundation. Perhaps it would make sense to see how the model that has scaled well for the foundation can be applied here: ASF Members elect a board board delegates to PMCs (no micromanagement, just delegation of broad goals) PMCs answer to the board Board answers to the Membership PMCs delegate to committers (no micromanagement just broad goals) Committers do the work and make localised decisions Committers are answerable to the PMCs Why can't the IPMC work like that? Well, to a large extent it does. Here are the same items expressed from the perspective of the IPMC and its relationship with PPMCs. No equivalent of ASF Members elect a board IPMC members delegate to the PPMCs (including Mentors) PPMCs answer to the IPMC IPMC answers to the Board PPMCs delegate to committers (no micromanagement just broad goals) Committers do the work and make localised decisions Committers are answerable to the PMCs Where this model breaks down is that the IPMC is too large to act with consistency and efficiency. The IPMC is kind of like the ASF Membership. The ASF Members list, for those unfortunate enough to be on it, occasionally blows up with problems for which there is no single, perfect solution. The IPMC list does just the same. The rest of the time everything runs smoothly. The way the foundation survives these episodes is to have an elected board that is responsible for navigating through those situations. They don't seek the one single right answer (because there isn't one), instead they listen to a set of options, each flawed in some way an they pick the one deemed to be least flawed from the foundations point of view. The board breaks deadlocks when they occur, the rest of the time the board does nothing more than provide sufficient oversight to ensure the PMCs can operate as Apache PMCs (it gets out of the way). The IPMC has no equivalent. So when it hits a problem with multiple potential outcomes - all flawed, it ends up in deadlock. Look back of the archives, this is happening increasingly often as the IPMC grows. We need a way to efficiently break deadlocks. Let me ask a question... Why shouldn't the IPMC create an equivalent to the one item in the above governance structure that is missing today. That is why shouldn't it have an equivalent of ASF Members elect a board. It would something like IPMC elect 9-15 Shepherds. These Shepherds are responsible for ensuring that the IPMC membership is heard and that decisions are made for the good of the IPMC. They approve membership of the IPMC, they approve project entry/graduation/retirement but, and this is critical, they report to the IPMC. Most of the time their role is one of delegation to the PPMCs, occasionally their role is to break a deadlock by listening to the IPMC and making the best decision it can. This need not change any other line in the existing governance. It need not change the IPMC relationship with the board. Mentors will still be IPMC members, with binding votes, etc. Since the Shepherds are accountable to the IPMC they must seek to do the right thing, or they will be replaced. Just as the Board can be replaced at any time if the Membership so desires. Of course, we could argue that the IPMC chair already has the authority to do all this. Indeed they do. However, expecting one individual to keep track of all the activity in our podlings is unreasonable. Furthermore, it is harder for one individual to make the hard decisions and suffer the mud slinging from those that don't like the outcome. Just a thought of course, my solution is as flawed as anyone elses and I look to the IPMC Chair to find the good enough solution that will allow us to move on (sorry Benson). Ross On 27 March 2013 11:55, Benson Margulies bimargul...@gmail.com wrote: I suppose that as chair I ought to be heard from here. I've been off for Passover for a bit. In my view, the IPMC manifests two problems. I'd like to label them as 'operational' and 'decision-making'. This thread is about decision-making, but with some people seeing using terms like 'disfunctional', I think it's important to keep 'function' in context. Operationally, we 'started' 1.3 years ago with an acute problem of under-supervised and/or 'malingering' podlings. Under Jukka's leadership, we made a series of incremental changes that have considerably improved the situation. On the other hand, the recent influx of many new podlings worries me, because 'improved' is not the same as 'fixed'. And I'm not entirely sure that 'fixed' is possible. I'd like to see us find more incremental changes that help further, and I'd like them to scale via some mechanism other than my own personal time. I see this as a reason to put more thought into shepherds and champions. But I don't see this situation as
Re: Vote on personal matters: majority vote vs consensus
On 27 March 2013 15:54, ant elder ant.el...@gmail.com wrote: On Wed, Mar 27, 2013 at 11:55 AM, Benson Margulies bimargul...@gmail.com wrote: Ok, i propose we have an experiment [1] where we try having a mentor or two who are not PMC members. Have some other experienced mentors helping to make sure nothing unfixable can go wrong, and just see how it goes for a while, reporting each month with the status. In general I'm all for more mentors, but if they are not IPMC members where will the binding votes for releases come from? Wouldn't a small experiment like this be worth trying before we drop something as fundamental as using consensus? There are so many issues being discussed in parallel I'm not sure which problem this experiment is designed to solve? Ross
Re: Creating announce@ lists by default
On Tue, Mar 26, 2013 at 6:14 PM, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Mar 26, 2013 at 4:05 AM, Noah Slater nsla...@apache.org wrote: I am under the impression that having a low-volume, high-signal announcement channel is generally beneficial to most projects that try it. I agree that such lists are useful. I like to subscribe to individual announce lists for security purposes because aggregate lists like debian-security-announce generally lag behind upstream. Individual dev lists and announce@a.o are too high traffic and programming text-based filters is tricky because conventions like ANNOUNCE are not adhered to 100% of the time. Do the general announce list lag behind because there are individual lists ? As to whether such lists should be encouraged for new podlings (probably by putting a stub in the proposal template alongside the other lists), I can't say that I have a strong opinion. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013 at 4:23 PM, Ross Gardler rgard...@opendirective.com wrote: On 27 March 2013 15:54, ant elder ant.el...@gmail.com wrote: On Wed, Mar 27, 2013 at 11:55 AM, Benson Margulies bimargul...@gmail.com wrote: Ok, i propose we have an experiment [1] where we try having a mentor or two who are not PMC members. Have some other experienced mentors helping to make sure nothing unfixable can go wrong, and just see how it goes for a while, reporting each month with the status. In general I'm all for more mentors, but if they are not IPMC members where will the binding votes for releases come from? From PMC members on general@ which is what happens for lots of poddlings now anyway as most don't get three mentors voting on their releases and have to come to general@. I'm not suggesting that we start off the experiment with a poddling having all non-PMC mentors so there would be other mentors with binding votes being active in the poddling. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Creating announce@ lists by default
On Wed, Mar 27, 2013 at 7:45 AM, Noah Slater nsla...@apache.org wrote: Bertrand, yes, I am not sold on the idea of doing it by default. But perhaps sort of advisory, highlighting it as an option, and giving reasons why it might be a good idea for some projects? What would I have to do to add that? If I prepare a patch to the docs, would it be CTR or RTC? The minute that is in the guides, I'm positive that 100% of new podlings proposals will request the list. Having said that, today any podling can create a JIRA issue with INFRA to request a new mailing list. Is that not a good solution ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (PODLINGNAMESEARCH-31) Establish whether Apache DeltaSpike is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615470#comment-13615470 ] Jason Porter commented on PODLINGNAMESEARCH-31: --- IIRC, Dan was the one to suggest DeltaSpike, being something (the spike) that filled all the deltas between what we have in Java EE 6 and what we'd like it to be. Establish whether Apache DeltaSpike is a suitable name Key: PODLINGNAMESEARCH-31 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: John D. Ament Attachments: deltaspike.com Bildschirmfoto 2013-03-27 um 12.58.58.png DeltaSpike is a portmanteau of Delta (for change) and Spike (for 'an abrupt sharp increase'). From the ASF perspective, it is a library of reusable CDI extensions and components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013 at 11:18 AM, Ross Gardler rgard...@opendirective.comwrote: Perhaps it would make sense to see how the model that has scaled well for the foundation can be applied here: ... [snip] ... Why can't the IPMC work like that? Well, to a large extent it does. Here are the same items expressed from the perspective of the IPMC and its relationship with PPMCs. Your proposal is not terribly different from proposals like what Chris floated a year or so ago. Yours adds a layer of entities. Chris' removes a layer. Chris' proposal is essentially that Incubating projects become PMCs instead of PPMCs. IIRC, his proposal still incorporated mentoring and oversight to ensure that incubating projects are operating according to Apache principles. Perhaps there's a model where incubating PMCs report directly to the board, as with Chris' proposal, but with a dotted-line reporting structure to a mentoring body. This mentoring body would be responsible for vetting releases and new committers as the IPMC does now. But its role would be more of a guiding role than an oversight role. The podlings I've participated in would not have suffered from such a model. Flex, for example, had a board member and 2 ASF members as mentors. The IPMC did not have to provide much insight beyond what we provided. The Incubator provides the following benefits to incubating projects: * mentoring on ASF principles and procedures * vetting of releases * help growing community * a temporary community while podling community develops It seems to me that a model like what Chris has proposed or what I am proposing could still provide all those benefits without the bureaucracy of a super-IPMC. Greg
Re: Creating announce@ lists by default
On 27 March 2013 16:28, Luciano Resende luckbr1...@gmail.com wrote: Do the general announce list lag behind because there are individual lists ? I see no reason why they would. On 27 March 2013 16:31, Luciano Resende luckbr1...@gmail.com wrote: The minute that is in the guides, I'm positive that 100% of new podlings proposals will request the list. This would be a positive outcome, from where I'm standing. Having said that, today any podling can create a JIRA issue with INFRA to request a new mailing list. Is that not a good solution ? Solution to what problem? As you point out, podlings can already create announce@ lists. I just figured that announce@ lists are probably a good thing for most projects, so we should mention them. -- NS
Re: Creating announce@ lists by default
On Wed, Mar 27, 2013 at 10:19 AM, Noah Slater nsla...@apache.org wrote: So we just set out a policy for podlings to follow that says something like: if you use a project-specific announce@ list, anything you send to it must also be copied to annou...@apache.org, and vice-versa. This is how I expect all announce lists to be used. Is there a way to automate what you just said ? Assuming the same restrictions to send announcements applies to both announce@ and project-announce@, then anything sent to project-announce@ gets automatically copied to annou...@apache.org ? Thoughts ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Creating announce@ lists by default
Putting it in policy is probably as close as we can get to automation. ;) On 27 March 2013 17:23, Luciano Resende luckbr1...@gmail.com wrote: On Wed, Mar 27, 2013 at 10:19 AM, Noah Slater nsla...@apache.org wrote: So we just set out a policy for podlings to follow that says something like: if you use a project-specific announce@ list, anything you send to it must also be copied to annou...@apache.org, and vice-versa. This is how I expect all announce lists to be used. Is there a way to automate what you just said ? Assuming the same restrictions to send announcements applies to both announce@ and project-announce@, then anything sent to project-announce@ gets automatically copied to annou...@apache.org ? Thoughts ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: Creating announce@ lists by default
On 27 March 2013 17:23, Luciano Resende luckbr1...@gmail.com wrote: On Wed, Mar 27, 2013 at 10:19 AM, Noah Slater nsla...@apache.org wrote: So we just set out a policy for podlings to follow that says something like: if you use a project-specific announce@ list, anything you send to it must also be copied to annou...@apache.org, and vice-versa. This is how I expect all announce lists to be used. Is there a way to automate what you just said ? Assuming the same restrictions to send announcements applies to both announce@ and project-announce@, I don't know if announce@project.a.o has the same restrictions. I've not found an example of a non-ASF address posting to such a list, but that does not mean it's not possible. then anything sent to project-announce@ gets automatically copied to annou...@apache.org ? Thoughts ? There may be good reasons for *sometimes* not copying announce@ASF. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Creating announce@ lists by default
On Wed, Mar 27, 2013 at 10:23 AM, Luciano Resende luckbr1...@gmail.com wrote: On Wed, Mar 27, 2013 at 10:19 AM, Noah Slater nsla...@apache.org wrote: So we just set out a policy for podlings to follow that says something like: if you use a project-specific announce@ list, anything you send to it must also be copied to annou...@apache.org, and vice-versa. This is how I expect all announce lists to be used. Is there a way to automate what you just said ? Assuming the same restrictions to send announcements applies to both announce@ and project-announce@, then anything sent to project-announce@ gets automatically copied to annou...@apache.org ? Thoughts ? I guess this is how it's done on announce@subversion, see [1] The mail to announce@subversion.a.o will also be forwarded to announce@a.o I'd be ok with this approach. [1] http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On 27 Mar 2013 16:43, Greg Reddin gred...@gmail.com wrote: On Wed, Mar 27, 2013 at 11:18 AM, Ross Gardler rgard...@opendirective.comwrote: Perhaps it would make sense to see how the model that has scaled well for the foundation can be applied here: ... [snip] ... Why can't the IPMC work like that? Well, to a large extent it does. Here are the same items expressed from the perspective of the IPMC and its relationship with PPMCs. Your proposal is not terribly different from proposals like what Chris floated a year or so ago. Yours adds a layer of entities. Chris' removes a layer. I disagree. Chris' proposal removes the IPMC thus making the board legally responsible for everything that committee does today. Yes it replaces it with an oversight body, but how does that scale? Mine simply proposes a way to break the occasional deadlocks in the IPMC by using an existing, but informal, layer - shepherds. Nothing else changes. The IPMC is not broken, it just has growing pains. Ross Chris' proposal is essentially that Incubating projects become PMCs instead of PPMCs. IIRC, his proposal still incorporated mentoring and oversight to ensure that incubating projects are operating according to Apache principles. Perhaps there's a model where incubating PMCs report directly to the board, as with Chris' proposal, but with a dotted-line reporting structure to a mentoring body. This mentoring body would be responsible for vetting releases and new committers as the IPMC does now. But its role would be more of a guiding role than an oversight role. The podlings I've participated in would not have suffered from such a model. Flex, for example, had a board member and 2 ASF members as mentors. The IPMC did not have to provide much insight beyond what we provided. The Incubator provides the following benefits to incubating projects: * mentoring on ASF principles and procedures * vetting of releases * help growing community * a temporary community while podling community develops It seems to me that a model like what Chris has proposed or what I am proposing could still provide all those benefits without the bureaucracy of a super-IPMC. Greg
Re: Creating announce@ lists by default
My personal experience: There are a few people registered to annou...@apache.org, but there is a low registration rate for the respective subproject lists. At least not for most projects. Thus said: if you would create an announce list for all projects and send the ANN mails only to those lists, then only 30% of the audience will receive it. Some projects don't even maintain separated dev and users lists. Thus I believe forcing an ann list for each and every project is an overkill. Oh, and while we are at it: some a.o projects have users@project.a.o (plural) and others have user@project.a.o (singular). We should at least unify this for the upcoming podlings pretty please ;) just my $2E-2 LieGrue, strub - Original Message - From: Luciano Resende luckbr1...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, March 27, 2013 7:14 PM Subject: Re: Creating announce@ lists by default On Wed, Mar 27, 2013 at 10:23 AM, Luciano Resende luckbr1...@gmail.com wrote: On Wed, Mar 27, 2013 at 10:19 AM, Noah Slater nsla...@apache.org wrote: So we just set out a policy for podlings to follow that says something like: if you use a project-specific announce@ list, anything you send to it must also be copied to annou...@apache.org, and vice-versa. This is how I expect all announce lists to be used. Is there a way to automate what you just said ? Assuming the same restrictions to send announcements applies to both announce@ and project-announce@, then anything sent to project-announce@ gets automatically copied to annou...@apache.org ? Thoughts ? I guess this is how it's done on announce@subversion, see [1] The mail to announce@subversion.a.o will also be forwarded to announce@a.o I'd be ok with this approach. [1] http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Creating announce@ lists by default
On 27 March 2013 18:37, Mark Struberg strub...@yahoo.de wrote: My personal experience: There are a few people registered to annou...@apache.org, but there is a low registration rate for the respective subproject lists. At least not for most projects. That's to be expected, though, right? We have something like 130 TLPs. Even if a TLP has a respectable amount of press/analysts/end-users subscribing to the announcement list, we'd not expect that number to be more than the overall foundation announcement list, which caters to a much bigger audience. Thus said: if you would create an announce list for all projects and send the ANN mails only to those lists, then only 30% of the audience will receive it. Some projects don't even maintain separated dev and users lists. Thus I believe forcing an ann list for each and every project is an overkill. I don't believe we should force an announce@ list on anybody. But I do think it might be a good idea to mention a few of the standard lists that projects might consider requesting. user@, dev@, announce@, etc. commits@ is required. When you're community grows, you may want to consider tickets@, and general@, etc. CloudStack had marketing@ before we graduated, even. Oh, and while we are at it: some a.o projects have users@project.a.o(plural) and others have user@project.a.o(singular). We should at least unify this for the upcoming podlings pretty please ;) Sounds sensible. -- NS
[VOTE] S4 0.6.0 Incubating Release Candidate 3
Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS We include a RAT check task. It requires to get - the .rat-excludes from the repository (https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=blob;f=.rat-excludes;h=fda230011164a53bd3089f9086c884918e0ea292;hb=refs/heads/dev) - the rat jar from the repository It can be run with : ./gradlew rat output Please cast your vote, thanks! Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Matthieu - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? gradlew and gradlew.bat don't have AL headers; nor does s4. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS The key entries don't have any human-readable headings, as required by the comments. For example: (gpg --list-sigs your name gpg --armor --export your name) this file. The --list-sigs command creates a readable header. We include a RAT check task. It requires to get - the .rat-excludes from the repository (https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=blob;f=.rat-excludes;h=fda230011164a53bd3089f9086c884918e0ea292;hb=refs/heads/dev) Why are the following excluded? logback.xml s4-checkstyle.xml s4-eclipse-format.xml XML supports header comments. - the rat jar from the repository It can be run with : ./gradlew rat output Please cast your vote, thanks! Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Matthieu - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
Hi, this is a very interesting proposal. Let me ask a few questions. On Wed, Mar 27, 2013 at 5:18 PM, Ross Gardler rgard...@opendirective.com wrote: Why shouldn't the IPMC create an equivalent to the one item in the above governance structure that is missing today. That is why shouldn't it have an equivalent of ASF Members elect a board. It would something like IPMC elect 9-15 Shepherds. These Shepherds are responsible for ensuring that the IPMC membership is heard and that decisions are made for the good of the IPMC. They approve membership of the IPMC, they approve project entry/graduation/retirement but, and this is critical, they report to the IPMC. Most of the time their role is one of delegation to the PPMCs, occasionally their role is to break a deadlock by listening to the IPMC and making the best decision it can. it sounds a little bit as the Shepherds would be the true PMC of the IPMC. It's interesting, because you would bypass the problem with IPMC members have binding votes, therefore everybody needs to be there. The term PMC is already in use, so you create a new term and give these group actual PMC-ship. Therefore it would be logic to me if the IPMC chair would be elected out of the Shepherds. Also if we follow this, Shepherds doesn't sound so nice. Actually it is a kind of Board. This need not change any other line in the existing governance. It need not change the IPMC relationship with the board. Mentors will still be IPMC members, with binding votes, etc. Since the Shepherds are accountable to the IPMC they must seek to do the right thing, or they will be replaced. Just as the Board can be replaced at any time if the Membership so desires. Nice. Of course, we could argue that the IPMC chair already has the authority to do all this. Indeed they do. However, expecting one individual to keep track of all the activity in our podlings is unreasonable. Furthermore, it is harder for one individual to make the hard decisions and suffer the mud slinging from those that don't like the outcome. I don't think a chair should act with authority. I also have not seen any place where it is said that a chair should dictate decisions or so. You would also bypass this problem with making multiple chairs. I believe it would relax the chair (generally spoken) a lot. And you bypass the problem that a strong chair is needed, which seems to be the case with 172 members. I was having the mentor = committer model in mind, which is similar to Chris model (i think). At least I would have the problem with the binding votes. One could only bypass it to give Mentor a binding vote as exception to other projects. Your proposal has an exception (the Shepherds) too. I like it though, but I am still not convinced if we need another layer of people - or if we just minimize the IPMC and give Mentors (= Committers) that binding vote. Just a thought of course, my solution is as flawed as anyone elses and I look to the IPMC Chair to find the good enough solution that will allow us to move on (sorry Benson). I look to all IPMC members. Cheers Christian Ross On 27 March 2013 11:55, Benson Margulies bimargul...@gmail.com wrote: I suppose that as chair I ought to be heard from here. I've been off for Passover for a bit. In my view, the IPMC manifests two problems. I'd like to label them as 'operational' and 'decision-making'. This thread is about decision-making, but with some people seeing using terms like 'disfunctional', I think it's important to keep 'function' in context. Operationally, we 'started' 1.3 years ago with an acute problem of under-supervised and/or 'malingering' podlings. Under Jukka's leadership, we made a series of incremental changes that have considerably improved the situation. On the other hand, the recent influx of many new podlings worries me, because 'improved' is not the same as 'fixed'. And I'm not entirely sure that 'fixed' is possible. I'd like to see us find more incremental changes that help further, and I'd like them to scale via some mechanism other than my own personal time. I see this as a reason to put more thought into shepherds and champions. But I don't see this situation as 'disfunctional'. On the decision-making front, recent phenomena have demonstrated to me that this group is not succeeding in applying consensus process to decision making. I could write five paragraphs on what that process is and what it requires, but I'm not inclined to. I support the proposal here to apply majority rules to IPMC membership. When consensus process fails here, we have endless email threads. Many of us find these stressful, time-consuming, and disheartening. Under the proposal at hand, we'd still DISCUSS, and I'd hope that we would all try to be thoughtful and constructive and look for ways to agree. However, after a certain amount of discussion, there would be a vote, and that would be that. If this 'works' -- if people
Re: Vote on personal matters: majority vote vs consensus
Sent from a mobile device, please excuse mistakes and brevity On 27 Mar 2013 20:12, Christian Grobmeier grobme...@gmail.com wrote: Hi, this is a very interesting proposal. Let me ask a few questions. On Wed, Mar 27, 2013 at 5:18 PM, Ross Gardler rgard...@opendirective.com wrote: Why shouldn't the IPMC create an equivalent to the one item in the above governance structure that is missing today. That is why shouldn't it have an equivalent of ASF Members elect a board. It would something like IPMC elect 9-15 Shepherds. These Shepherds are responsible for ensuring that the IPMC membership is heard and that decisions are made for the good of the IPMC. They approve membership of the IPMC, they approve project entry/graduation/retirement but, and this is critical, they report to the IPMC. Most of the time their role is one of delegation to the PPMCs, occasionally their role is to break a deadlock by listening to the IPMC and making the best decision it can. it sounds a little bit as the Shepherds would be the true PMC of the IPMC. No. The IPMC would be the true IPMC, but they elect a representative body to make the IPMC function more efficiently. That body remains answerable to the IPMC. This is important because the mentors should be the ones making recommendations about graduation, report approval etc. More importantly only PMC members have binding votes on releases. The shepherds delegate all this to the PPMC (and its mentors). The shepherds only act to ensure the PPMC is capable, unhindered and healthy. Also if we follow this, Shepherds doesn't sound so nice. Actually it is a kind of Board. Yes it is. I avoided new names to prevent the false impression that this is adding new layers. The Shepherds already do almost everything I'm suggesting. The only addition is for them to be the ones who break consensus deadlocks. Why them? Because their role means they have more visibility into the breadth of the Incubator than many IPMC members. I don't think a chair should act with authority. Sometimes it is necessary, but I agree that it should be very rare. The problem with the IPMC is that it is needed too frequently. My proposal, as you observe, provides a representative group, answerable to the IPMC, to build consensus on these occasions. I am still not convinced if we need another layer of people - or if we just minimize the IPMC and give Mentors (= Committers) that binding vote. I have no doubt that my proposal is imperfect, let's find the holes and see if they are pluggable. Chris' model is similar in some ways as has been observed. I'm yet to see how the scale problem will be solved, but maybe I'm remembering the proposal incorrectly, In think a fundamental difference between Chris' radical model and mine is revolution vs evolution. Personally I think the current IPMC model works well 98% of the time, so evolution is appropriate, Just a thought of course, my solution is as flawed as anyone elses and I look to the IPMC Chair to find the good enough solution that will allow us to move on (sorry Benson). I look to all IPMC members. I meant Benson should coordinate, not dictate :-) Thanks for your useful critique. Ross Cheers Christian Ross On 27 March 2013 11:55, Benson Margulies bimargul...@gmail.com wrote: I suppose that as chair I ought to be heard from here. I've been off for Passover for a bit. In my view, the IPMC manifests two problems. I'd like to label them as 'operational' and 'decision-making'. This thread is about decision-making, but with some people seeing using terms like 'disfunctional', I think it's important to keep 'function' in context. Operationally, we 'started' 1.3 years ago with an acute problem of under-supervised and/or 'malingering' podlings. Under Jukka's leadership, we made a series of incremental changes that have considerably improved the situation. On the other hand, the recent influx of many new podlings worries me, because 'improved' is not the same as 'fixed'. And I'm not entirely sure that 'fixed' is possible. I'd like to see us find more incremental changes that help further, and I'd like them to scale via some mechanism other than my own personal time. I see this as a reason to put more thought into shepherds and champions. But I don't see this situation as 'disfunctional'. On the decision-making front, recent phenomena have demonstrated to me that this group is not succeeding in applying consensus process to decision making. I could write five paragraphs on what that process is and what it requires, but I'm not inclined to. I support the proposal here to apply majority rules to IPMC membership. When consensus process fails here, we have endless email threads. Many of us find these stressful, time-consuming, and disheartening. Under the proposal at hand, we'd still DISCUSS, and I'd hope that we would all try to be thoughtful and
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. In the binary release, we do include 3rd party products and the NOTICE and LICENSE files are updated accordingly, during the build process. You may check the binary release artifact. In the source release, we do not include those products and the NOTICE and LICENSE files take that into account. S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS The key entries don't have any human-readable headings, as required by the comments. For example: (gpg --list-sigs your name gpg --armor --export your name) this file. The --list-sigs command creates a readable header. I followed the instructions for signing apache releases http://www.apache.org/dev/release-signing.html and didn't see requirement for human readable headings in the KEYS file. (and didn't understand the comments were mandating that) If this is a requirement for the release, I suppose I can update the KEYS file in the subversion repository with the proper headers? We include a RAT check task. It requires to get - the .rat-excludes from the repository (https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=blob;f=.rat-excludes;h=fda230011164a53bd3089f9086c884918e0ea292;hb=refs/heads/dev) Why are the following excluded? logback.xml s4-checkstyle.xml s4-eclipse-format.xml XML supports header comments. There is no reason. Those files are for setting up the development environment and configuring the log output. Other xml files in the release do bear the ASL header. Is that blocking the release? I hope these explanations bring clarification. Regards, Matthieu - the rat jar from the repository It can be run with : ./gradlew rat output Please cast your vote, thanks! Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Matthieu - 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
Re: [VOTE] Graduate Apache Onami as TLD
+1 Niall On Tue, Mar 26, 2013 at 7:04 AM, Christian Grobmeier grobme...@gmail.com wrote: Hi all, Apache Onami entered incubation before more than 3 months. Since then the community has proven to be pretty active and healthy. A few releases were made and the status page has been completed: http://incubator.apache.org/projects/onami.html Three new committers were added in the past weeks. SVNSearch shows, there is clearly one guy who is outstanding in his motivation, but others do commit as well: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fonami Mailinglist Archives show the Community is discussing in public: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/ The community consists of new Apache-people and some more experienced Apache-people. I do not see any problem regarding developing the Apache-way. A [DISCUSS] thread on general@ showed no concerns. Simone Tripodi has been elected as the new Chair: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/%3CCAPFNckisQo29Ssy6Q-WkKgAZLRa3VW%2B7afLCEbbVy6HsWX_rAg%40mail.gmail.com%3E A resolution has been created and voted on: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/%3CCAPFNckjDujef_G6t1%3DjuTdOvuXsgxWq-%2BGntiOMdFpE%3DgwReDg%40mail.gmail.com%3E The community vote for becoming a TLD was successful too: http://onami-dev.markmail.org/thread/6w2dvrs3bj755kdm We now kindly ask the IPMC to review our findings and vote on the Onami graduation. [ ] +1, yes propose the graduation of Apache Onami to the board [ ] -1, no, don't let Apache Onami graduate, because... Thanks, Christian -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
The first thing I'd like to do, coordination-wise, is to call a vote on the proposal to decide things by majority. I think that this would help with some of the problems we hit, and we can meanwhile continue to discuss larger structural changes. On Wed, Mar 27, 2013 at 4:48 PM, Ross Gardler rgard...@opendirective.comwrote: Sent from a mobile device, please excuse mistakes and brevity On 27 Mar 2013 20:12, Christian Grobmeier grobme...@gmail.com wrote: Hi, this is a very interesting proposal. Let me ask a few questions. On Wed, Mar 27, 2013 at 5:18 PM, Ross Gardler rgard...@opendirective.com wrote: Why shouldn't the IPMC create an equivalent to the one item in the above governance structure that is missing today. That is why shouldn't it have an equivalent of ASF Members elect a board. It would something like IPMC elect 9-15 Shepherds. These Shepherds are responsible for ensuring that the IPMC membership is heard and that decisions are made for the good of the IPMC. They approve membership of the IPMC, they approve project entry/graduation/retirement but, and this is critical, they report to the IPMC. Most of the time their role is one of delegation to the PPMCs, occasionally their role is to break a deadlock by listening to the IPMC and making the best decision it can. it sounds a little bit as the Shepherds would be the true PMC of the IPMC. No. The IPMC would be the true IPMC, but they elect a representative body to make the IPMC function more efficiently. That body remains answerable to the IPMC. This is important because the mentors should be the ones making recommendations about graduation, report approval etc. More importantly only PMC members have binding votes on releases. The shepherds delegate all this to the PPMC (and its mentors). The shepherds only act to ensure the PPMC is capable, unhindered and healthy. Also if we follow this, Shepherds doesn't sound so nice. Actually it is a kind of Board. Yes it is. I avoided new names to prevent the false impression that this is adding new layers. The Shepherds already do almost everything I'm suggesting. The only addition is for them to be the ones who break consensus deadlocks. Why them? Because their role means they have more visibility into the breadth of the Incubator than many IPMC members. I don't think a chair should act with authority. Sometimes it is necessary, but I agree that it should be very rare. The problem with the IPMC is that it is needed too frequently. My proposal, as you observe, provides a representative group, answerable to the IPMC, to build consensus on these occasions. I am still not convinced if we need another layer of people - or if we just minimize the IPMC and give Mentors (= Committers) that binding vote. I have no doubt that my proposal is imperfect, let's find the holes and see if they are pluggable. Chris' model is similar in some ways as has been observed. I'm yet to see how the scale problem will be solved, but maybe I'm remembering the proposal incorrectly, In think a fundamental difference between Chris' radical model and mine is revolution vs evolution. Personally I think the current IPMC model works well 98% of the time, so evolution is appropriate, Just a thought of course, my solution is as flawed as anyone elses and I look to the IPMC Chair to find the good enough solution that will allow us to move on (sorry Benson). I look to all IPMC members. I meant Benson should coordinate, not dictate :-) Thanks for your useful critique. Ross Cheers Christian Ross On 27 March 2013 11:55, Benson Margulies bimargul...@gmail.com wrote: I suppose that as chair I ought to be heard from here. I've been off for Passover for a bit. In my view, the IPMC manifests two problems. I'd like to label them as 'operational' and 'decision-making'. This thread is about decision-making, but with some people seeing using terms like 'disfunctional', I think it's important to keep 'function' in context. Operationally, we 'started' 1.3 years ago with an acute problem of under-supervised and/or 'malingering' podlings. Under Jukka's leadership, we made a series of incremental changes that have considerably improved the situation. On the other hand, the recent influx of many new podlings worries me, because 'improved' is not the same as 'fixed'. And I'm not entirely sure that 'fixed' is possible. I'd like to see us find more incremental changes that help further, and I'd like them to scale via some mechanism other than my own personal time. I see this as a reason to put more thought into shepherds and champions. But I don't see this situation as 'disfunctional'. On the decision-making front, recent phenomena have demonstrated to me that this group is not succeeding in applying consensus process to
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. I followed the git link above that you provided, then clicked on tree. I don't know otherwise how to review the source tag. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. These also need to be added to the GIT copies; and the GIT tag must agree with the source files in the archive(s). gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does not make the rules. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. That may not have been the correct decision. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. In the binary release, we do include 3rd party products and the NOTICE and LICENSE files are updated accordingly, during the build process. You may check the binary release artifact. In that case, the wording is wrong; it should say includes, not uses. I've now had a look at the binary lib/ directory, and there are a lot of 3rd party (non-ASF) jars there that don't appear to be mentioned in the LICENSE file. Even if they use AL 2.0, they need to be mentioned, but of course the AL 2.0 text does not need to be repeated. It's helpful to include the version of the jar that is being included, because it can change between versions. The binary archive does not include gradlew.bat - is that intentional? In the source release, we do not include those products and the NOTICE and LICENSE files take that into account. That's good. But not so good are the names; one is LICENSE and the other is NOTICE.txt. The should both have a .txt extension or neither. Also the source archive contains the 3rd party library lib/gradle-wrapper-1.4.jar This is not mentioned in the LICENSE file (nor NOTICE.txt, but that may not be required). It seems strange to have a jar in a source library. Maybe that is a mistake, but if it is supposed to be there it needs to be reflected in the NL files. RELEASE_NOTES.html does not have an AL header (nor is it valid HTML). Various s4-benchmarks/config/ files don't have AL headers. The logback.xml files don't have AL headers. S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS The key entries don't have any human-readable headings, as required by the comments. For example: (gpg --list-sigs your name gpg --armor --export your name) this file. The --list-sigs command creates a readable header. I followed the instructions for signing apache
Re: Vote on personal matters: majority vote vs consensus
On Mon, Mar 25, 2013 at 12:12 AM, Roman Shaposhnik r...@apache.org wrote: On Sat, Mar 23, 2013 at 1:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: One alternative to going for full-on majority voting is to recognize that a larger group is much more likely to have noisy vetoes by requiring that successful votes have n positive votes and m negative votes subject to some condition on n and m. Majority requires n m, strict Apache consensus requires n = 3 and m == 0. It is easy to imagine other conditions such as n = 4 and m = 2 which still have some of the flavor of consensus in that a minority can block a decision, but allow forward progress even with constant naysayers or occasional random vetoes. Personally, I'd suggest keeping these options in our backpocket and turning back to considering them in case a simple majority proposal runs into an opposition somehow. At this point, I'd rather try a simple solution first. I was in favour of simple majority - but a vote passing with, for example 9+1 and 8-1 is as bad IMO as a vote failing because of alot of +1 and only one -1. So I've changed my mind on this - I think it should be 3/4 majority. This avoids a small minority stopping something, but also doesn't completely throw out consensus. Niall Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
This whole exercise is pointless. Just drop the notion of vetoes for all IPMC votes and carry on as before. Sent from my iPhone On Mar 27, 2013, at 6:11 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:12 AM, Roman Shaposhnik r...@apache.org wrote: On Sat, Mar 23, 2013 at 1:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: One alternative to going for full-on majority voting is to recognize that a larger group is much more likely to have noisy vetoes by requiring that successful votes have n positive votes and m negative votes subject to some condition on n and m. Majority requires n m, strict Apache consensus requires n = 3 and m == 0. It is easy to imagine other conditions such as n = 4 and m = 2 which still have some of the flavor of consensus in that a minority can block a decision, but allow forward progress even with constant naysayers or occasional random vetoes. Personally, I'd suggest keeping these options in our backpocket and turning back to considering them in case a simple majority proposal runs into an opposition somehow. At this point, I'd rather try a simple solution first. I was in favour of simple majority - but a vote passing with, for example 9+1 and 8-1 is as bad IMO as a vote failing because of alot of +1 and only one -1. So I've changed my mind on this - I think it should be 3/4 majority. This avoids a small minority stopping something, but also doesn't completely throw out consensus. Niall Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Wed, Mar 27, 2013 at 3:11 PM, Niall Pemberton niall.pember...@gmail.com wrote: I think it should be 3/4 majority. I agree that supermajority would be better than simple majority here. Moving to simple majority seems too radical. Over time it's more prone to building a PMC that cannot easily agree on things. If consensus has proven too difficult to reach for a group this large, then softening it a bit to supermajority seems like a better first step then moving all the way to simple majority. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On Thu, Mar 28, 2013 at 12:11 AM, Niall Pemberton niall.pember...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:12 AM, Roman Shaposhnik r...@apache.org wrote: On Sat, Mar 23, 2013 at 1:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: One alternative to going for full-on majority voting is to recognize that a larger group is much more likely to have noisy vetoes by requiring that successful votes have n positive votes and m negative votes subject to some condition on n and m. Majority requires n m, strict Apache consensus requires n = 3 and m == 0. It is easy to imagine other conditions such as n = 4 and m = 2 which still have some of the flavor of consensus in that a minority can block a decision, but allow forward progress even with constant naysayers or occasional random vetoes. Personally, I'd suggest keeping these options in our backpocket and turning back to considering them in case a simple majority proposal runs into an opposition somehow. At this point, I'd rather try a simple solution first. I was in favour of simple majority - but a vote passing with, for example 9+1 and 8-1 is as bad IMO as a vote failing because of alot of +1 and only one -1. So I've changed my mind on this - I think it should be 3/4 majority. This avoids a small minority stopping something, but also doesn't completely throw out consensus. +1 - this sounds like the most reasonable proposal of all. -- Best Regards, -- Alex
Re: [VOTE] Graduate Apache Onami as TLD
+1 (binding). Good luck! Cheers, Chris On 3/26/13 12:04 AM, Christian Grobmeier grobme...@gmail.com wrote: Hi all, Apache Onami entered incubation before more than 3 months. Since then the community has proven to be pretty active and healthy. A few releases were made and the status page has been completed: http://incubator.apache.org/projects/onami.html Three new committers were added in the past weeks. SVNSearch shows, there is clearly one guy who is outstanding in his motivation, but others do commit as well: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fonami Mailinglist Archives show the Community is discussing in public: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/ The community consists of new Apache-people and some more experienced Apache-people. I do not see any problem regarding developing the Apache-way. A [DISCUSS] thread on general@ showed no concerns. Simone Tripodi has been elected as the new Chair: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/% 3CCAPFNckisQo29Ssy6Q-WkKgAZLRa3VW%2B7afLCEbbVy6HsWX_rAg%40mail.gmail.com%3 E A resolution has been created and voted on: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/% 3CCAPFNckjDujef_G6t1%3DjuTdOvuXsgxWq-%2BGntiOMdFpE%3DgwReDg%40mail.gmail.c om%3E The community vote for becoming a TLD was successful too: http://onami-dev.markmail.org/thread/6w2dvrs3bj755kdm We now kindly ask the IPMC to review our findings and vote on the Onami graduation. [ ] +1, yes propose the graduation of Apache Onami to the board [ ] -1, no, don't let Apache Onami graduate, because... Thanks, Christian -- http://www.grobmeier.de https://www.timeandbill.de - 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
[jira] [Commented] (PODLINGNAMESEARCH-31) Establish whether Apache DeltaSpike is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616084#comment-13616084 ] Charles Moulliard commented on PODLINGNAMESEARCH-31: Name is well established in (Apache) opensource community, web site has been revamped, we also have a logo. Don't think that we should loose our time to find another name which is from a branding/technical point of view always expensive. Establish whether Apache DeltaSpike is a suitable name Key: PODLINGNAMESEARCH-31 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: John D. Ament Attachments: deltaspike.com Bildschirmfoto 2013-03-27 um 12.58.58.png DeltaSpike is a portmanteau of Delta (for change) and Spike (for 'an abrupt sharp increase'). From the ASF perspective, it is a library of reusable CDI extensions and components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
