avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: separation of voting and commit priviledges
Date Fri, 01 Nov 2002 08:10:53 GMT

I have been lucky enough to be invited into the Avalon committer 
community on a similar timescale to yourself.  Since arriving I have 
been honored to work amongst the excellent minds here.  As I see it the 
community focuses on the brilliance of Avalon-Framework and its 
patterns. With that focus we are united.  It is the goal that draws us 
all together.  Where the community has differing interests is that we 
are maintaining multiple containers.  Some like Phoenix & ECM have been 
in development for multiple years and have been used in anger over a 
similar timescale.  Some like EOB are young and yet to be used by a 
single organisation anywhere near a live situation!!  All our containers 
are different in goal, niche configuration and implementation.  That is 
fine by me.  I focus on the A-F commonality and am not upset that my 
Avalon buddies show little interest in EOB :-)  I am unlikely to make 
any money from EOB as I've targeted the magic price point of zero, but 
then that characterises all of our containers (not withstanding the 
ultra-secret efforts of the lurkers to this list).

Anyway, I am happy with this community.  I am happy that we all have 
good things to say about all of the containers even the one that we do 
not work on. I am happy that we hold all Avaloners in high esteem, all 
containers as worthy efforts.  I'm happy that we agree that A-F is 
Jakarta's most important project (though we know that non-Avaloners take 
some convincing).

Where we differ dude, is on the assertion that the community needs to 
evolve.  I believe it essentially does not.  We also differ on sub 
projects <not> working together.  I think there is plenty of synergy. 
 There are tens of excalibur libraries used by other excalibur projects 
and avalon based containers.

I'd like to state a new problem we may well disagree on. I am 
deliberately brief here:  

    The more dissent we repeatedly post here, the more community mind share
    we lose (regular developers & committers).  I'd really prefer more 
    and less 'playground' comments.


- Paul

PS - I'd also like to see more xdocs work, but as is typical with my 
experience with xdocs, developers cannot be convinced to work on them 
unless they are tied to their computers and make to listen to Janice 
Joplin for 72 hours continuously.

> 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:   
>> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <mailto:avalon-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message