avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: separation of voting and commit priviledges
Date Thu, 31 Oct 2002 11:16:44 GMT

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:

>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>


Stephen J. McConnell

digital products for a global economy

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