Clarifications about Phoenix (Re: Auto-assembly)

[Nicola Ken Barozzi <ni...@apache.org>]

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.

+1

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

I agree with you.

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

I use James for my company, and I'm the administrator and the one 
"politically" responsible for it. Don't worry, the last thing I want to 
see is James in difficulty over Phoenix.

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

Let me explain this one more time, to be as clear as possible: nobody is 
going to be forced in *any* way, to switch to an alpha container.

The new container we are talking about is going to be developed in 
parallel with the *necessary* development of current released code, of 
which Phoenix is very important. And nobody has said that big parts of 
Phoenix code won't be used in that container.

When we will have a new *stable* container, that has already passed 
alpha and beta cycles, and that has a very clear and well defined 
migration path avaliable for Phoenix, *then* we will simply /encourage/ 
users to switch to the new container.

This means that for months Phoenix will be maintained and actively 
developed where the features represent needed evolutions for Phoenix users.

The development of Phoenix in these months will hopefully bring it 
nearer in features and semantics to the new container, so that when the 
concete possibility of a switch will come it will be as painless as 
possible.
That's why I questioned this feature: if it's in the path that we all 
agree on and that will be somewhat in the new container, it's important 
that it's done, else it would only do harm. Since it seems that it's 
welcome, I'm happy it will be brought forward.

I have already explained it before, I do it now, and I will do it every 
time it's needed. Apache has a reputation for stability, and we will 
continue on this path.

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

Avalon-Phoenix developers, please.

We don't want to make you loose their support: we want you to have the 
full support of all the Avalon community.

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

Sure. That's why we are on the new container, to do it all together.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>