avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Auto-assembly
Date Sun, 01 Dec 2002 22:07:40 GMT
Darrell DeBoer wrote:
> On Sun, 1 Dec 2002 21:21, Stefano Mazzocchi wrote:
> 
>>Darrell DeBoer wrote:
>>
>>>On Thu, 28 Nov 2002 04:45, Stefano Mazzocchi wrote:
>>>
>>>>Nobody is proposing to stop Phoenix development, Peter. Stop crying.
>>>
>>>Ummm, Stefano, you might want to read the entire content of the emails
>>>you send. This one seems self-contradictory. Or just a troll.
>>>
>>>(from further up you email)
>>>
>>>
>>>>>On Wed, 27 Nov 2002 18:30, Nicola Ken Barozzi wrote:
>>>>>
>>>>>>We are discussing about a new single container with profiles, wouldn't
>>>>>>be better to put all further development on hold, switch to
>>>>>>maintainance mode and focus on that?
>>>>>
>>>Sounds like someone proposing to stop Phoenix development to me.
>>
>>Nicola proposed to put on hold 'further development' of Phoenix. Which
>>(at least to me) means: let's top having containers as playgrounds for
>>framework-related stuff that should be discussed and voted by the avalon
>>development community.
>>
>>My response was that nobody here is proposing to 'shut down phoenix' and
>>stop its development and leave all the phoenix users with nothing to
>>work on and without bugs to be fixed.
>>
>>So, one thing is 'development', another thing is 'further development'.
>>But you're right, it wasn't clear, so thanks for asking me to clarify.
>>
>>What I want to see ending is the use of containers to implement stuff
>>that influence Avalon as a framework and create 'dialects' of framework
>>usage.
>>
>>This is what Nicola is proposing to stop.
>>
>>This is what I agree on.
>>
>>If the community agrees on this proposal, Phoenix (and all the other
>>containers controlled by the Avalon development community) will
>>implement what the Avalon community decides and all the
>>framework-related decisions will have to go thru community consensus.
>>
>>This will, hopefully, reduce current Avalon 'balkanization'.
>>
>>If the community agrees on this proposal and single developers want to
>>go ahead without community consensus they can:
>>
>>  1) follow the rules of revolutionaries
>>
>>  2) go somewhere else
>>
>>There is no other alternative around here.
>>
>>All avalon developers must understand that.
> 
> 
> Thanks for the clarification. I must say that as a James developer and a 
> Phoenix user, I'm really against any proposal that would slow down the 
> provision of new and *necessary* features in Phoenix. 

The proposal is not meant to 'slow down' anything, Darrell. It's meant 
to put an end on fragmentation of avalon implementations.

> We waited a *long* time for a stable, released version of Phoenix. And it's 
> great, but we want more. We want to be allow developers to simply "drop-in" a 
> mailet jar file with some config and for it to just work.

Dude, I hear you. Cocoon needs *exactly* the same hotdeployment 
capabilities.

What we want it to have *all* the avalon developers working on solving 
the same issues *together*. That might be harder and slow at first, but 
this is a long-term goal: provide a united and strong avalon development 
community that will concentrate on functional requirements of all the 
avalon users, but without fragmenting the avalon brand into myriads of 
different containers.

> I personally want 
> it to be easier to compose components of finer grained sub-components. These 
> sorts of features probably require new features (like auto-assembly) for 
> Phoenix.

Exactly. But if you talk about this on phoenix-dev or james-dev, the 
other people that use Cocoon and have similar issues, will not be able 
to suggest things. Or you to them.

See my point? we are not trying to blast Phoenix or to kick people out, 
rather the opposite: we want to work together for a better Avalon!

> We're about to commence on a bunch of new developments in James, and I for one 
> want to continue on top of the stable base we've got today. But I don't want 
> to be told we need to switch to a new, alpha container, and wait for the 
> talk-fest to be over.

Hey man, look: how can avalon force its users to do something, even if 
it wanted to? we want to 'unify' this community, we don't want to 
fragment it any more than it already is.

Cocoon and James are the most important Avalon users. They have very 
different requirements, yet very common ones.

Is it possible to provide a migration path that allows Cocoon and James 
to be based on different profiles of the same container and yet being 
back compatible?

I think it's possible.

For sure, I'll be the first one against Avalon imposing 
back-incompatible changes without a nice migration path to its users.

> Please don't force us to fork Phoenix internally (or somewhere else) to get 
> the features we need. (No, this isn't a threat, or even likely. But I'd vote 
> +1 if I *really* had to.) I'd hate to see us lose the support of Peter D, 
> Paul H, Eung Ju, Leo S and the other Phoenix devs, who have provided so much 
> support over time.

Same here dude. Cocoon will write its own avalon implementation and 
maintain it internally, but this is the *very last* resort.

> This is Open-Source, right? We do this for fun, a challenge, and to make the 
> world a better place. Let's not make it harder than it has to be.

Oh, please, I'm not trying to make things harder for the fun of it. Why 
should I? I care about Avalon as a user as much as you do.

And this is why I'm concerned about avalon community fragmentation.

James and Cocoon are based software maintained by a fragmented 
community. the history of open source dynamics show that this is a very 
dangerous thing. signs of internal friction and cracks have already 
appeared. I want avalon to be surrounded by a united community that 
cares about the framework.

Today it's hard to tell if people care about the framework more than 
they care about its implementations and this is bad.

-- 
Stefano Mazzocchi                               <stefano@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>


Mime
View raw message