Regarding Phoenix, and my book

[Berin Loritsch <bl...@citi-us.com>]

All this turmoil and change couldn't be coming at a worse time.  I am still
working
on my book (I know it is horribly past due).  However with all the talk
about scrapping
old code and working one "One container to rule them.  One container to find
them,
and in the darkness bind them." (with appologies to J.R.R. Tolkien), we are
now
rendering a project in work obsolete before it is done.

The thing is that both Framework and Phoenix are released code.  Both of
them
have consumers and users.  I am _really_ glad we have a users list or we
would
be scaring off what few we have right now.  What are we going to say to
those
projects that depend on Phoenix, or those of us who managed to convince
their
superiors to use the released and ready Phoenix?

The bottom line is this:

* Phoenix is too big to be a reference implementation, so under Stefano's
  "Cooperate or else" proposal we would have to move Phoenix somewhere else.

* Phoenix is released code and needs to be supported.  The question is
where.

* There are a few developers who do the bulk of the work, but I can't give
you
  absolute statistics as to the size of its community.  I have the
impression that
  the developer community is not large at all.

* If Phoenix has to move outside of Avalon, then I can host it in one of my
  D-Haven.org projects at sourceforge.  I consider this the last resort, and
  I really don't want to see it happen--but if it means that Phoenix lives
on,
  all I have to do is point the readers of my book to the new resting place.


The question is what is best for the community?  We need to decide quickly,
because I have deadlines I am already past and all this uncertainty is only
serving
to delay me further.  We need to be clear about our intentions regarding
Phoenix at this point.  If Phoenix will no longer exist as part of the "new
Avalon",
then It is welcome with my external projects.  If Phoenix has guarantees
that it
will be supported while the work on the "supercontainer" continues then we
can leave it here.

My intentions are not to be devisive, but I have real needs that are met by
the existing code.  All I want is guarantees from the community that Phoenix
is continued to be supported while the "supercontainer" is still vaporware.
When the supercontainer is finished, we can decide what to do at that point.


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

Re: Regarding Phoenix, and my book

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

Berin Loritsch wrote:
> All this turmoil and change couldn't be coming at a worse time.  I am still
> working on my book (I know it is horribly past due).  However with all the talk
> about scrapping old code and working one "One container to rule them.  One container to find
> them, and in the darkness bind them." (with appologies to J.R.R. Tolkien), we are
> now rendering a project in work obsolete before it is done.

I never saw anything about scraping stuff, but about building something 
new. The important thing is what we create, not what we destroy.

> The thing is that both Framework and Phoenix are released code.  Both of
> them have consumers and users.  I am _really_ glad we have a users list or we
> would be scaring off what few we have right now.  What are we going to say to
> those projects that depend on Phoenix, or those of us who managed to convince
> their superiors to use the released and ready Phoenix?

Tha Phoenix is not going anywhere.
That we are working on a new generation.
That we will make an easy and painless upgrade path when we are ready.

> The bottom line is this:
> 
> * Phoenix is too big to be a reference implementation, so under Stefano's
>   "Cooperate or else" proposal we would have to move Phoenix somewhere else.

Not necessarily with the tiered approach.

> * Phoenix is released code and needs to be supported.  The question is
> where.

Here.

> * There are a few developers who do the bulk of the work, but I can't give
> you   absolute statistics as to the size of its community.  I have the
> impression that  the developer community is not large at all.

If it's just to provide support and bigfixes, it's more than ok, given 
the dedication and work they pour into it.

> * If Phoenix has to move outside of Avalon, then I can host it in one of my
>   D-Haven.org projects at sourceforge.  I consider this the last resort, and
>   I really don't want to see it happen--but if it means that Phoenix lives
>  on, all I have to do is point the readers of my book to the new resting place.

I'm strongly against Phoenix leaving. Phoenix is not a threat, it's an 
asset. Phoenix is code, our problem is in the community.

> The question is what is best for the community?  We need to decide quickly,
> because I have deadlines I am already past and all this uncertainty is only
> serving to delay me further.  We need to be clear about our intentions regarding
> Phoenix at this point.  If Phoenix will no longer exist as part of the "new
> Avalon", then It is welcome with my external projects.  If Phoenix has guarantees
> that it will be supported while the work on the "supercontainer" continues then we
> can leave it here.

I don't see why we cannot support something that we made.
Rephrasing: we *must* support our products.

> My intentions are not to be devisive, but I have real needs that are met by
> the existing code.  All I want is guarantees from the community that Phoenix
> is continued to be supported while the "supercontainer" is still vaporware.
> When the supercontainer is finished, we can decide what to do at that point.

Definately.
And the new container can become the new Phoenix, as it will be the new 
Fortress and the new Merlin.

-- 
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: Regarding Phoenix, and my book

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

>As for Phoenix:
>
>Phoenix stays. I agree with your assessment of the situation:
>
> + Phoenix is released code. 
>
> + We have to accomodate the users.
>
>/LS
>
>  
>

+1

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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

RE: Regarding Phoenix, and my book

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@citi-us.com] 
> 
> * Phoenix is too big to be a reference implementation, so 
>   under Stefano's "Cooperate or else" proposal we would have 
>   to move Phoenix somewhere else.
 
Not necessarily.

 1) As I understand it, Stefano wants us to work *towards* one 
    container.

 2) I have yet to see a detailed description of just what his 
    proposal is.

 3) "Cooperate or else" need not mean one container. It just 
    means that if we have 20 different containers, all of those
    are created and scoped based on concensus. That is, no
    fragmentation. See my exchange with Sam:
    http://marc.theaimsgroup.com/?l=avalon-dev&m=103797449904891&w=2



As for Phoenix:

Phoenix stays. I agree with your assessment of the situation:

 + Phoenix is released code. 

 + We have to accomodate the users.

/LS


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

Re: Regarding Phoenix, and my book

[Berin Loritsch <bl...@apache.org>]

Noel J. Bergman wrote:

>>All this turmoil and change couldn't be coming at a worse time.  I am
>>    
>>
>still
>  
>
>>we are now rendering a project in work obsolete before it is done.
>>[Framework and Phoenix] have consumers and users.  I am _really_ glad
>>we have a users list or we would be scaring off what few we have right
>>    
>>
>now.
>
>Uh ... some of us users are here now because of the turmoil.  If you think
>it has been hidden, you are seriously misled.  And, as a user,, I am
>starting to feel better because I am starting to see the beginnings of a
>plan to work together.
>

I never assumed it was hidden.  It just isn't as in-your-face.


---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com

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

RE: Regarding Phoenix, and my book

["Noel J. Bergman" <no...@devtech.com>]

> All this turmoil and change couldn't be coming at a worse time.  I am
still
> we are now rendering a project in work obsolete before it is done.
> [Framework and Phoenix] have consumers and users.  I am _really_ glad
> we have a users list or we would be scaring off what few we have right
now.

Uh ... some of us users are here now because of the turmoil.  If you think
it has been hidden, you are seriously misled.  And, as a user,, I am
starting to feel better because I am starting to see the beginnings of a
plan to work together.

Phoenix is a real platform with customers (including me).  I don't believe
that it is going away.  Might there be a future implementation of Phoenix
that shares much more common code with other containers?  I would certainly
hope so.  But why do you feel that such an event is cause for concern?

> under Stefano's "Cooperate or else" proposal we would have
> to move Phoenix somewhere else.

I don't consider that to be a correct interpretation of the situation.  And
if that premise is incorrect, then the conclusions are wrong.

And I don't believe that the next stage of container development is going to
composed of large jumps off of cliffs.  I hope that it will be characterized
by incremental communal recognition, agreement, and merger of common
elements.  Stephen McConnell looks to have a nice list of starting points
for discussion, and Peter Donald has some, too.  If everyone can continue to
focus on making the possible happen then I think things will move forward
smartly.

	--- Noel


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