You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Farr, Aaron" <Aa...@am.sony.com> on 2004/03/22 16:47:08 UTC
Another Avalon Roadmap
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Another Avalon Roadmap
Posted by Stephen McConnell <mc...@apache.org>.
Hi Aaron:
This is a short reply because my monitor is about to disintegrate and I
have to switch it off fast. Getting item (1) closed means some
reshuffling of fortress code which would be preferable after SVN is in
place. Reshuffling basically involves putting in a proper gump build
and sub-project structure and resolving the sourceresolver dependencies
(or moving sourceresolver under fortress if separation is problematic).
The sourceresolver is also required by monitor and xmlutil (both
referenced by Cocoon). Once these are sorted I'll post a message to the
gump list to see what we can do to setup a separate legacy gump
descriptor that references a specific branch following which close of
items (2) and (3).
Cheers, Stephen.
Farr, Aaron wrote:
> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org