Hello.
The PMC has already taken a peek at this roadmap which I put together. It
is by no means official at this point -- more just a general guide right now
and my thoughts on how to proceed. There's been some positive feedback and,
thus far, no strong objections. I wanted to send it out to the dev list for
more comments though.
1. Clean up Excalibur and Fortress
A lot of this work has been done already, recently thanks to Niclas.
The clean up should not involve any code changes or new development,
just getting things into a very stable, buildable situation. A key
factor here would be clean GUMP builds.
2. Release of Excalibur and Fortress
We just had a release, but depending on the number of changes in
step #1, another release may be required. This is mostly just so
users who are still working with Excalibur and Fortress don't have
to get the cleaned up versions via CVS but can just download them
from our distribution mirrors. This is an "optional" step -- it may
be competely unnecessary if the existing releases will suffice. If
we need the release, I volunteer to be release manager.
3. ECM/Fortress/Phoenix move to Emeritus Container status
Call 'em Emeratus, Legacy, Stable, whatever. Just don't call them
"dead." It gives people the jibblies. We create a section of the
site (maybe even CVS) for these containers/projects. They will be
listed as stable though not actively developed. People are free to
use them with the understanding that further development (by Avalon)
has halted. We'll need to come up with a policy for patches
submitted by users.
NOTE: They will most likely be termed "legacy".
4. Spin off Avalon Extras
There may be some aspects of Avalon we can and should spin off into
other groups if they are willing to take them. Candidates include:
logkit --> Apache Logging
avalon-repository --> depot
and a couple of the excalibur projects (like excalibur-events).
Again, this step, like all the rest, would require community
consensus and appropriate steps.
NOTE: This step is not guaranteed. We'll need to take into
account what's best for everyone.
5. Avalon TCK
This may be the harder part. We'll fix all those 'holes' in the
standards (http://wiki.apache.org/avalon/AvalonStandards) and
establish a TCK. This involves finally fixing the meta-mess.
6. TCK Implementation
While 5 & 6 are obviously tightly interwoven, I separated them out.
This part will involve bringing Merlin up to the TCK requirements.
7. Legacy migration
At this point we should be able to properly offer users a migration
path to the latest iteration (and hopefully more stable) of Avalon.
This may be by offering special "personalities" or "policies" which
offer backwards compatible support. It may also involve tools for
updating old components. This will not necessarily be simple, but
we need to have a stable target (TCK) to shoot for before we can
offer this sort of support. Until then, users have the stable
emeritus containers to work with or the latest Merlin container.
8. Refinement of the Container(s)
At this point we'll have a more stable environment to develop in.
We'll have a TCK and migration tools. We can now work on refining
and extending our platform. This may involve further development of
Leo's Aspects idea, leading to a more flexible Avalon container
system.
9. Additional User Support -- tools, docs, etc.
At this point we can also focus on delivering a better package to the
user. This involves more tool support (Merlin Developer) and more
complete documentation. Maybe we'll even get some more complete
Avalon "distributions" out there -- a range of prebuilt Avalon
solutions (small, medium, large).
10. Planet Avalon and Beyond
I'm adding this somewhat "tongue-in-cheek". I don't know if a
Avalon Planet is even possible or if I want it. But by this point
such dreams of grandeur are more within grasp.
Comments welcome.
J. Aaron Farr
� SONY ELECTRONICS
� DDP-CIM
� (724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
