Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 34900 invoked from network); 31 Oct 2002 11:16:33 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 31 Oct 2002 11:16:33 -0000 Received: (qmail 2387 invoked by uid 97); 31 Oct 2002 11:17:36 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 2341 invoked by uid 97); 31 Oct 2002 11:17:36 -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 2329 invoked by uid 98); 31 Oct 2002 11:17:35 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DC1111C.7020504@apache.org> Date: Thu, 31 Oct 2002 12:16:44 +0100 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: separation of voting and commit priviledges References: <1036019589.1311.189.camel@lsd.bdv51> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Hi Leo: I read through your email and to be frank, I felt somewhat angry and sad all at the same time. I felt sad because what your wrote about is the "playground syndrome" that is so prevalent in Avalon. What I felt angry about is that it's not a passive syndrome, its an active syndrome. I got involved in Avalon about two years ago. After figuring out all of the Avalon stuff I got to point where the "Avalon Concept" was having a real impact on my own development and the development of the people I was working with. During that first year my primary contribution to the Avalon Community was helping other people understand Avalon and Phoenix. One year later was voted in as a committer, armed and ready to contribute to the Avalon project with some important components. What happened was that I was that I was assigned my own playground - avalon-apps/enterprise - lots of freedom to do what I wanted and no constraints. But what I wanted was to get involved in a real process about delivering real components that would deliver real value to Avalon "the Community". That never happened. When I joined up as a committer the last thing I wanted was to be shuffled of to a playground. What I wanted was the opportunity to leverage a bunch of people I really respected. I wanted to leverage ideas, beliefs, opinions - and through this process, enhance and improve not only the content that I committed, but also I to pay-back the confidence that the Avalon project had placed in me when they voting me into this community. It's two years later and what is the impact outside of my delegated playground ... I've managed to push though the deprecation of the Component interface through the work on the service package (not a lot of code but a lot of effort to handle the volume of email at the time). It's something I really believe will enhance Avalon buy simply eliminating the Avalon lock-in (giving people more choice and more liberty gets more people engaged). I think this was an important contribution to the framework and a contribution reached through a solid engagement and participation of the community. I've also contributed to Avalon the Merlin story - something positioned somewhere between ECM and Phoenix. I look at this work as achieving two objectives - an expression of interest from myself in where I would like to see Avalon going in the future, and secondly, and concrete attempt to resolve the technical/community divide in Avalon that is reflected by the ECM/Phoenix split. Two cultures - two communities, that only serve to weaken the real potential of Avalon as the complete component solution. Even today, with an order of magnitude increase in the market recognition of the value of component oriented programming, the hot press coming out of Avalon is the release of incompatible and divergent containers (Phoenix and Fortress). And yet, both address different concerns and could really incorporated in a single comprehensive solution. Why do these two different solutions exist? Why is it that they have not merged already? Why was Merlin even necessary? They exist because somewhere in the history of Avalon there was a fundamental split - Phoenix went down the direction of static component management, ECM went in the direction to dynamic component management - playground policies got their first foot in the door. And years later, their differences remain unresolved - and yet with only a few months work, Merlin 2 manages to bridge both abstractions. What's wrong with this story? The problem is the continuation, no! escalation of "playground principals" - principals that fly in the face of the needs and interests of our end-user. Take Cocoon as an example - Cocoon is on the brink of engaging in a process of block based development and moving towards this from an ECM legacy position. Where is the "Avalon Project" solution.... block no longer exist in Phoenix - Fortress has no notion of blocks or anything close to block assembly. Is there something we need to be addressing relative to our end user priorities? Why aren't sub/sub projects working together - because territories have been marked out - unspoken rules that imply territorial restrictions. Avalon is in my opinion the most important project in Apache. But I believe that Avalon is only as strong as its community. For the community to work together it must abandon playground policies and really engage in addressing the difficult issue of bringing all of this work together. If the Avalon community cannot do this the Avalon the Community has nothing to offer. If the Community has nothing to offer that Avalon has nothing to offer its users. This community *must* be totally committed to its core and its own integrity. Any suggestion of the departmentalizing/separation of voting and commit privileges is simply reinforcing a cancer that will only lead to further fragmentation of interests. Avalon will only evolve if its community evolves. That means that every single member of this community must be given the real and tangible potential to contribute his or her best in every aspect of Avalon's evolution. From this perspective I'm very strongly in support of Avalon "the community" taking up the challenge and leveraging the opportunities for real evolution offered by escalation to a top-level project. Cheers, Steve. Leo Simons wrote: >All, > >following an interesting conversation between PD & Nicola on >general@commons (somewhere in messages 100-200) and also other threads >regarding voting on that list, I figured it might be a good idea to say >some things right here about the moral separation of voting and commit >priviledges @ avalon. > >Avalon is a big project where not everyone knows all of the codebase or >works on it (sure as hell I don't know all of it :). Yet every avalon >committer has full access to all the cvs modules. This has many >advantages, like allowing everyone to do useful stuff like applying >patches, fixing language or adding docs. > >However, informally, it is considered ill-practice here (I'd assume by >everone...) to participate in voting (other than lazy approval and/or >non-binding :) on pieces of code for which you are not a 'significant' >contributor/maintainer and for pieces of code for which you do not have >sufficient knowledge to make an informed decision. > >Of course, 'significant' is something not so easily defined or perhaps >agreed upon when you have as informal a setup as we do (which might be >part of the problem behind our recent flamefests and yet one more reason >to eliminate scope creep and/or setup our own PMC - to be able to make >some things like this more formal); the 'informal' part also makes our >community work less transparantly (well, especially that this moral >guideline is also undocumented ;). > >This is not to discourage anyone from participating in discussions where >they don't immediately see all sides of the story immediately or haven't >been involved with a piece of code before......on the contrary! That'd >be a disaster. I'm just voicing some more thoughts on voting behaviour >before heading to bed......if it all sounds silly just ignore me :) > >weltrusten (g'night), > >- Leo > > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: > > > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: