Berin Loritsch wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
It very much concerns me where there is considerable pressure on one
hand to be non-devisive (i.e. no -1s) and on the otherhand, the
suggestion that someone thinks that the PMC in general thinks its not
our problem. Yes it is our problem - the only issue is when
do we bite
the bullet and bring Phoenix into Avalon. That will require
effort and
resource and will. I don't think those ingridients will be available
until we get the container API in place. In the meantime we have two
options:
(b) the easy option
Let Phoenix development continue in an independent path.
(a) the hard option
Stop further divergence of Phoenix.
Cheers, Steve.
My suggestion is to bring up the issue on the Pheonix dev list,
and require them to bring Phoenix into a compilable and consistent
build.
This is te Phoneix dev list - the merge of phoenix-dev with avalon-dev
was completed a couple of days ago.
As to option "a" versus "b", I don't want to stand in the way of
further development, but we need to make sure the standards are
the same.
I don't want to stand in the way of furter development either - but I do
want to make sure that the development is rationale.
As it stands *now* with the current understanding of the contracts
(or lack thereof) of Avalon Framework 4.1 compliance, Phoenix _is_
Avalon Framework compatible. That is the only level of compatibility
that is guaranteed for Phoenix at this time.
As we further refine what our contracts are, we need to communicate
those issues to the Phoenix Dev list.
I suggest we give the Phoenix developers one week to make it stop
the GUMP build errors. If it cannot, we revert the code base to
the last CVS date that it was working.
+1
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
