Re: Auto-assembly

[Stefano Mazzocchi <st...@apache.org>]

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.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



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

Re: Auto-assembly

[Stefano Mazzocchi <st...@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.
> 
> 
> 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                               <st...@apache.org>
--------------------------------------------------------------------



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

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>

Re: Auto-assembly

[Darrell DeBoer <da...@apache.org>]

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. 

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.

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.

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.

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.

-- 
cheers,
Darrell DeBoer

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