avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [VOTE] New Development Direction
Date Tue, 03 Dec 2002 15:16:40 GMT
(changing back the subject to something merrier)

On Tue, 2002-12-03 at 07:14, Stephen McConnell wrote:
> Berin Loritsch wrote:
> > We either shoot for the moon, or we play it safe.
> 
> Shoot for the moon and play safe.

Agreed.

I'm going to sprout some thoughts on this rather than write a very
directed reply. I think otherwise I won't be saying what I want to say.
Apologies in advance ;)

			---- = O = ----

For our company, I need a stable standalone container (ie
Avalon-Phoenix) right now and I need a stable servlet-embeddable
container (hoping it'll be Avalon-Fortress) in mid-january.
I need the stable Avalon-Framework to go with them. I need both of them
to support both ServiceManager and ComponentManager, and I need the
proxy features that wrap non-Components as Components. I need to
commercially support these products. I get paid to do so and paid to
provide support and work on them. I'll play safe regardless of what
avalon as a whole decides on this matter because I need to.

I suspect many people are in similar situations. We don't want these
people, contributing based on immediate need, to stop their work; we've
worked long and hard to have something stable and we need to harvest
some of the fruits of that labour.

Whether we call future stuff "Avalon 4.1.4", "Avalon 4.2", "Avalon 4.4"
or "RealCool Java Platform XP, .Net Edition", the APIs need evolution
rather than revolution to guarantee stability.

I think we all more or less agree on the big picture here: current
Avalon releases (all the stuff in
http://jakarta.apache.org/builds/jakarta-avalon/release/) are way cool,
need, deserve, and will get evolutionary development and support. 

			---- = O = ----

Avalon as a community needs to come together and do some refocusing.
We've got some nasty episodes behind us and we need to drop all that.
We're well underway to doing all that; I think it'll work out and avalon
will come out of this process as one of the healtiest, leanest, meanest
and coolest open source projects on the planet. There'll probably be a
lot of "blood, sugar, sex, magic" involved, but it'll work.

I don't think everyone believes that yet but I'm confident that everyone
will in a few months when we are back on track.

Regardless, we've spent a lot of time talking about the why's and the
hows of that and we're ready to "get our hands dirty", define charters,
bylaws, move stuff around, work on cool new code together, etc etc.
Everything is in place to make that happen. This is the big task
immediately ahead of us.

			---- = O = ----

We've also gained a lot of experience since first releasing Framework
4.0 and ECM 4.0, gained new developers with new ideas, gained insights
from seeing our code in actual use, and many people are eager to put all
that new knowledge to use. This is something both fun to do (hence good
for the community) and something that might result in better code. The
not fun part of it (coding compatibility is not fun IMHO :) will happen
because there will be need for it.

How this new development takes place and which direction it goes in,
no-one knows for sure....as long as the entire community is part of the
new development I'll be real happy and I'm sure lots of cool stuff can
come from it.

Maybe we want to start with a common meta model, maybe with an
"ubercontainer", maybe with "Avalon-Framework 5", maybe all at once.
It's not the real point which areas we want to revolutionize. If it
makes sense to do so, good. Shoot for the moon, or mars. If we get
there, everyone's happy. If we don't, we'll have a solid orbital base to
return to.

			---- = O = ----

There's three things on the table right now:

1 - community "reboot", along with setting up charter, bylaws etc. Very
important this happens correctly, thoroughly and in good spirit if
possible, with good participation from everyone involved.

2 - continuing work on existing releases. There's a need for this stuff,
and if the avalon project doesn't support it, things will just move
elsewhere along with the people that need it.

3 - work on "next-gen" stuff where it makes sense to have "next-gen"
stuff.

We've more or less decided on (1), now we just need to get that underway
together with the other projects working on this. (2) is going to happen
simply because that's how OSS works. (3) is going to happen in some
areas because it makes sense and people want to work on it.

+1 on making (1) the primary focus
+1 on allowing (2) to continue (ie -1 on a "maintainance mode only")
+1 on allowing (3) to happen as well (ie +1 on "controlled
community-wide revolution")

Do we need to agree now that the stuff that comes out of the next-gen
will replace the current products eventually? Yes. Is that something to
vote on? dunno. But I don't think it's an if/else decision.

cheers,

- Leo


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


Mime
View raw message