Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 45266 invoked from network); 4 Dec 2002 21:04:05 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Dec 2002 21:04:05 -0000 Received: (qmail 16595 invoked by uid 97); 4 Dec 2002 21:05:10 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 16524 invoked by uid 97); 4 Dec 2002 21:05:09 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 16508 invoked by uid 98); 4 Dec 2002 21:05:09 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Server-Uuid: D7F7A26C-BD1B-4CCD-9949-79C53AF4322A Message-ID: From: "Stepanossov, Kirill" To: "'Avalon Developers List'" Subject: RE: Avalon voting process Date: Wed, 4 Dec 2002 16:03:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) X-WSS-ID: 11F0B2311352768-02-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sorry for noise here... but it looks both Berin and Stephen are right - the existence of veto as well as majority voting can be abused and both your justification are correct. Well... one of you is optimistic the other one is pessimistic with regards to "ability" of Avalon community and its developers... so why wouldn't you just look at what/who you have now in board and then based on that knowledge come to compromise conclusion... or just assign a person("judge"?) who should decide if the veto is valid in arguments ? -----Original Message----- From: Berin Loritsch [mailto:bloritsch@citi-us.com] Sent: Wednesday, December 04, 2002 3:34 PM To: 'Avalon Developers List' Subject: RE: Avalon voting process > From: Stephen McConnell [mailto:mcconnell@apache.org] > > Berin Loritsch wrote: > > >I propose that we follow the voting process outlined > >by Incubator. > > > > It looks good in terms of committer procedures. > A lot of the loose ends are getting cleaned up. > > >It is standard across all the projects > >I have seen. It addresses voting process of the community > >at large, but does not address the voting process of > >the PMC. > > > > Correct. > > > > >I still have yet to see other charters besides the XML > >one, and voting guidelines do not constitute a charter. > >I suggest that changes to the charter and voting guidelines > >be treated as code changes, with the stipulation that only > >PMC votes are binding. > > > > -1 > > NO, NO, NO, NO. > > I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN. > > NOT EVER - NEVER. Calm down. Keep in mind what a valid veto is (in another version of this mail). > >That allows a PMC member to veto > >a change with proper justification. > > > > Incorrect - any justification - feeble, profound, fantasy, etc. and > nothing to fallback on. We have today a majority voting > process. We can > change that thought a majority vote. That's it - there are no other > rules applicable here. Please - just use the structure we > have and don't > imply anything different with a PMC vote. I also don't want to be railroaded again--or did you miss that when you steamrolled the Avalon PMC through? I want the ability to say "Hold on, you need to slow down. There are more things to think through". With mere majority voting, my call to slow down will likely get overrun and then I am left holding the bag and trying to clean up your mess. Again, I assert that a proper veto as I outlined in another mail must be supported. A proper veto is not "I don't like it", that is invalid. A proper veto is accompanied by a reasonable explanation AND a counter-proposal. > >Proper justification > >should also have a counter-proposal so that the rest of > >the PMC knows *how* to rectify the situation. > > Just image for a moment that I really object to something (like your > ideas about voting on the PMC). And lets assume that your model is in > place. And lets assume that you and I disagree on something > similar. And > lets assume that my arguments and your arguments are both > well prepared > and rationale. Your solution creates a deadlock - you have > destroyed the > intrinsic value of the PMC - and that it be able to do things > when such > need arrives. You don't need to look very far back into > Avalon history > to see evidence of this. I'm not ready to bet the form on that not > happening again. > > Today - we have a majority rules on the PMC. Today, we have not voted on any PMC bylaws, and until I started bringing up the subject everyone was quiet. -1 on majority rules. It opens the door to steamrolling through concepts, ideas, etc. that are in favor of certain individuals but not the whole of Avalon. I repeat, I will not be left holding the bag from yours or anyone else's pushing through something before it is completely thought out. Period. I am just as unyielding on this point as you are on unanimous votes. I AM open to two-thirds majority of the PMC with voting open for an entire week. However simple majority doesn't work either. It's too easy to pull the wool over someones eyes for the length of time for a quick vote--and then the community regrets the outcome of the decision. The consequences of PMC resolutions are far greater than code changes, so I want something that will *force* us to work together on a solution we can all live with. I hope I am very clear on the matter. I am in favor of an Avalon PMC, but I am against the manner in which it came into being. I do not want to go through that again. > In the meantime - please not more assertions of what rules > apply - there > are rules already in place. Lets focus on charter - not > procedure - and > drop any discussion about policy to apply with result to charter or > policy evolution. It simple - a majority of the PMC voter to > change the > charter - the change gets escalated to the Board, the board does it > stuff. If that's no ok - then raise a vote on the PMC list. -1 for the reasons stated above. 2/3 majority is acceptable. Again, I am against the way things were steamrolled through to create the Avalon PMC, and I don't want to be subject to that again. > ----------ooo0ooo----------- > > You may sense a certain aggression/frustration here. That is brought > about by the inability of this community to deal with the > problems back > in July/August - it was complicated by the inability of the > Jakarta PMC > to address the issue. Even the board didn't address the issue on the > table at the time. Nobody took a position - not structure in > the entire > Apache organization was willing to step in with a closure. Yes - Pete > got kicked - but that wasn't the subject of the Jakarta/Board > discussion > before - that was probably more of a surprise to me than to > any of you. > What I do know is that those types issues MUST be address by > the Avalon > PMC. If you continue along the lines your describing - your just > creating the comfortable environment where you simply isolate > yourself > away from the potential of having to take a difficult decision. Look, I am able and willing to make very difficult decisions. I have made many more before Avalon was a part of my involvement. Those decisions impacted myself, my family, and other people. I am not afraid of standing for what I believe in. I find it a strength. The important thing is this: I don't want to be held responsible for the rash decisions of others. Simple majority opens the door for that. Mob rule did not work for Greece, and I don't think it will work here. > As a PMC member - I REFUSE to let a similar situation arise for other > members of the community. I will do everything I can to > ensure that the > PMC is an instrument that has balls and ability. And I'm > confident that > providing those attributes are held up with respect - that we > will never > need to use them. Today the PMC has balls - please don't try to take > that away. Its abilities will evolve through attention and > consideration > to the charter and procedures, and progressively, through > respect from a > united community. Also keep in mind that the veto Peter issued you back in August would not have been valid under my proposed definition of veto. -- To unsubscribe, e-mail: For additional commands, e-mail: ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- To unsubscribe, e-mail: For additional commands, e-mail: