> 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. 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. 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. I know there are Phoenix developers who can pick up where Peter left off. I have a feeling he was in the midst of a bunch of changes/updates to Phoenix/Info when his commit privs were suspended. It presents a problem in that Phoenix development has essentially stopped in the middle of a change. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
