Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev@jakarta.apache.org>
Subject: Re: Map and Array Dependencies
From: Leo Simons <leosimons@apache.org>
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Cc: Phoenix Development <avalon-phoenix-dev@jakarta.apache.org>
In-Reply-To: <200210012027.51011.peter@apache.org>
References: <000101c2692d$290b81e0$0801a8c0@Lagrange>
	<1033466247.1543.83.camel@lsd.bdv51>  <200210012027.51011.peter@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 01 Oct 2002 14:32:39 +0200
Message-Id: <1033475560.1542.167.camel@lsd.bdv51>
Mime-Version: 1.0

On Tue, 2002-10-01 at 12:27, Peter Donald wrote:
> On Tue, 1 Oct 2002 19:57, Leo Simons wrote:
> > true. Avalon doesn't offer a convenient way to satisfy all use cases it
> > wants to satisfy.
>=20
> There is no magic bullet and there never will be.=20

That was exactly my point I guess =3D)

> > yup. I don't have a better answer than anyone else to this dilemma. All
> > I know is that it would be very nice for me, and I think for many avalo=
n
> > users, to have only bugfixes, docs, testing etc for phoenix for like 6
> > months or so.
>=20
> why would we want to hobble Phoenix in that way?

it's finally been released as stable. In my (yes, limited) experience
with software development, once something is marked 'stable', some
people will finally start submitting bug reports or even bothering
looking under the hood.

Phoenix is a bit exceptional as it has had a long alpha and beta road,
so there might be only a few issues. It seems there are always twice the
amount you expect though.

that's why =3D)

> > The answer to questions like the one leading to the changes we're
> > talking about now could be "we don't support this directly. Wait until
> > phoenix 5 or so or solve at the application level". It's about choosing
> > between stability/compatibility and continuous improvement. It seems I'=
m
> > wrong in this particular case, but on a larger scale it is something
> > where we need to shift the balance towards stability.
>=20
> It has already happened. If you have not been taking notice of the commit=
s you=20
> will have missed that this is exactly what is happening. Almost all the w=
ork=20
> that is going into Phoenix (and Fortress for that matter) at this stage i=
s=20
> consolidation.

(for other english impaired:

con=B7sol=B7i=B7date

   1. To unite into one system or whole; combine: consolidated five
separate agencies into a single department.
   2. To make strong or secure; strengthen: She consolidated her power
during her first year in office.
   3. To make firm or coherent; form into a compact mass.)

I think you mean 2 & 3 from the above =3D)

> Parts are being extracted and unit tested to a far greater degree than be=
fore.=20

which is worthy of whoo-hoohs. It just seems to me that as there is
still so many unit tests to be/being added, it is inevitable there will
be bugs to be found and fixed.

> Features that we have been putting off for ages are being added in and un=
it=20
> tested.=20

which is the part I find puzzling, I guess. I guess I'm not so confident
as you that this won't collide with the finding and fixing of existing
issues.

> For example we have talked about allowing Map as dependencies since befor=
e you=20
> were involved with Avalon - way back when it was just me Berin, Fede and=20
> Stefano. Arrays have been "approved" before but no one ever got around to=
=20
> implementing them.=20

ahh. I hope you understand how it looked to me: a new concept added to
released code without any prior discussion as to how/what/why/etc.

> If you think you have something to offer then participate.

In this case (and also wrt interceptor architecture, dynamic dependency
resolutions, etc) it makes no sense whatsoever for me to get involved
and do coding. I'd be in over my head, and in the way.

But I feel I do have something to offer, like voicing user (and
executive management!) fears wrt ever changing feature sets. I
understand it can be annoying when you finish a few hours of coding and
then hear someone say "but won't it impact backwards compatibility?",
but I think it is still important the question is asked, and answered.

When/if we have a 'complete' set of specs/unit tests/regression tests,
that will happen automatically. We're not there yet so I'll keep moaning
about it from time to time.

> If you don't want=20
> to see any progress for whatever reason then don't. Simple as that really=
.

If only it were :)

> ------------------------------------------------------------
>  militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------=20

how appropriate :)

cheers,

Leo


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>