Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 69114 invoked from network); 19 Nov 2002 02:57:54 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Nov 2002 02:57:53 -0000 Received: (qmail 26946 invoked by uid 97); 19 Nov 2002 02:58:11 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 26746 invoked by uid 97); 19 Nov 2002 02:58:06 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 26629 invoked by uid 98); 19 Nov 2002 02:58:02 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: , Subject: Re: [Proposal] Breaking up Avalon Date: Mon, 18 Nov 2002 07:19:29 +1100 User-Agent: KMail/1.4.2 References: <200211171918.29177.peter@apache.org> <1037532855.1426.53.camel@lsd.student.utwente.nl> In-Reply-To: <1037532855.1426.53.camel@lsd.student.utwente.nl> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211180719.29862.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sun, 17 Nov 2002 22:34, Leo Simons wrote: > I personally think that making phoenix a new top level project would be > bad for apache as a whole because of the grossly overlapping concerns > between any such phoenix project and a possible avalon project; we woul= d > have rather permanent fragmentation of community. Phoenix has been in line for graduating out of Avalon for a very long tim= e. It=20 has had the momentum, community and support for a very long time. I have=20 worked to discourage that behaviour through a number of different strateg= ies.=20 The phoenix-dev and apps lists were specifically created to give extra sp= ace=20 and to avoid a split. Everytime the issue gets raised I would always sugg= est=20 we put it off to when Phoenix was a released product or to some nebulous=20 future point in time. The main reason was this was because Avalon has a severe brand management= =20 problem. Before "Avalon" existed - when "Avalon" was just a code name for= a=20 version of the the "Java Apache Server Framework" - it had problems then.= I=20 expected that Phoenix would eventually start to gather some good karma/br= and=20 and it would rub off on Avalon proper. This would lead to a better=20 development environment and a more active Avalon community. Think of it as similar to Cocoon. Many of the successes of Avalon have be= en=20 tied to Cocoon successes. Many developers first learn about Avalon from=20 Cocoon. And many Avalon decisions were made for the benefit of Cocoon.=20 I saw that synergy as being great and I believed that if the same could b= e=20 true with Phoenix then Avalon would be sooo much better off. This was=20 starting to happen. We had our first release and if we continue down this= =20 path we will soon have a very nice platform - which will hopefully channe= l=20 some more interest back into Avalon. I had hoped to keep this internal to= =20 Avalon because it would create closer ties. If that can't be then so be i= t. However the response so far has been encouraging. Mostly it has been of t= he=20 form "about time!", "do it anyway", "easier sell to boss" etc. As to overlapping charters. It is true that there is a degree of overlap = - the=20 new project would differ in that it is product-centric. It would all be a= bout=20 the development of a single container and thus many things that would be = in=20 scope for Avalon will be out of scope for Phoenix and vice versa. It is=20 expected that Phoenix will still use A-F and parts of Avalon Excalibur an= d=20 that there will be a high degree of cross talk. The end result will be two communities but they need not be conflicting b= ut=20 can cooperate. Some believe that there are already two communities in Ava= lon=20 - in which case the split is more than overdue anyways. > I think that this would be bad from the perspective of users of apache > software because it becomes difficult to choose between what would > become competing projects (right now, we as avalon community can say "g= o > use Avalon Phoenix or Avalon ECM, this-and-that version" and the > competition is internal). Not wanting competition is NOT a good reason to try and block said=20 competition. After all that has happened in Avalon I would have hoped tha= t=20 this would be obvious. Competition should be encouraged, embraced and bro= ught=20 into the fold. If merges can not happen for technical reasons then obviou= sly=20 different markets were being served by competing codebase and thus they m= ay=20 not really compete but compliment. --=20 Cheers, Peter Donald ---------------------------------------- "Liberty means responsibility. That is=20 why most men dread it." - Locke ----------------------------------------=20 -- To unsubscribe, e-mail: For additional commands, e-mail: