> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Leo Simons
>
> Hi gang,
>
> let's get everyone's agendas out on the table and figure out where we
> all want to take avalon in 2003, and then lets see how much
> we can get
> those various directions to converge. Good idea?
Great idea.
> My idea is to kick of some discussion here, then when it gets
> somewhat
> difficult to maintain any roadmap doc, we move the roadmap to
> the wiki
> (keeping discussion here).
> My idea is not to make something authoritive, just to figure out what
> various developers want to work on, and then get any problems the PMC
> might have with that (basically if it doesn't fit with the board
> resolution, we either must try and get the board to accept a new
> resolution or change plans) on the table too.
>
> Starting of....some bullets to comment on (no ordering yet ;):
+1
> 1. Infrastructure
> -----------------
> Mostly boring tasks if you ask me, but it needs doing.
>
> - move to avalon.apache.org (think Paul's on this)
> - move over mailing lists to avalon.apache.org (think this might be
> difficult from an infrastructure point)
> - refactor CVS (or move to svn! Apache Commons is getting svn!)
Really? Then we might want to upgrade for Avalon!
> - get a better build system in place (centipede, maven or
> something else)
So far Centipede and Maven are the best choices. As long as we
need to add in our own tasks like generating meta-data, or generating
bytecode, then Centipede might be the better choice for two reaons:
1) standard integration with Forrest (focus on doc generation and
site management)
2) Easy to incorporate project specific plugins (i.e. meta-gen and
family) without requiring the user to install stuff separately.
> - convert all docs over to forrest (right?)
:) I believe so. That way we can get rid of all the extra JARs
that we have simply for building docs. We can also get rid of
recursive dependencies.
> 2. Procedure, policy, guideline
> -------------------------------
> Something I also find boring, but quite vital to the project.
> Hopefully
> we can refer or copy-n-paste a lot from other projects.
>
> - write avalon charter
+1
> - write avalon project docs (ie something like the jakarta
> 'bylaws' but
> shorter and referring to "default" where possible)
+1 -- But not quite like 'bylaws'. Apache has a set of
Bylaws which all projects have to abide by. It is
more the guidelines to which we adhere (fitting within
the bylaws).
> - document some undocumented stuff procedure stuff like
> - release plan
+1
> - voting guidelines
+1 We have a general agreement on *how* to vote. The only
issue was some redefinition of PMC chair responsibilities
which we can't do. All we need to do is clean this up.
> - committer 'internship'
+1 Are you referring to the de facto standard of 6 months
involvement in most projects before comit rights are granted?
> 3. Dealing with 'legacy' code
> -----------------------------
> The Avalon codebase (all cvses together) is big, too big.
>
> - remove stale code that hasn't been released before
+1 Zip it up and remove the CVS stuff. The archive can be
placed on the server for download if it is necessary, or
moved to another project (like commons) if it is more
appropriate.
> - move code not fitting for the avalon project under the wings of
> another PMC, or perhaps to sourceforge
+1.
> - deprecate ECM (but we need fortress or ubercontainer first!)
I think Stephen will be happy with Fortress release if after
we are done with that we help him get Merlin ready. I think
that will help us understand each other better and provide
a foundation for ubercontainer cooperation. We will know
the strengths and weaknesses of each project.
> 4. Work on existing code
> ------------------------
> - do needed maintainance on "Developing with Avalon"
+10
> - do some Andy-Oliver-style example-based documentation
+1
> - maintainance releases of existing code
+1
>
> 5. Work on new code
> -------------------
> This is the 2nd most important bit (I feel a charter is
> really needed,
> too). How are we going to go about container convergence?
>
> - Phoenix 4.3, 4.4, 4.5?
> - Fortress 1, 1.1, 1.2?
> - Avalon5?
> - Merlin1?
> - UberContainer?
> - Containerkit2?
> - AvalonJ2ME?
My thoughts on this are:
Phoenix 4.x.y progression.
Fortress 1.0
- Finish docs
- Make release
Merlin 2.0 (which becomes the new "Fortress")
- Merge the best parts of Fortress into Merlin
- Provide migration tools and compatibility.
- Provide docs
Avalon5 interfaces
Ubercontainer
I think we can make Avalon5 both easier to use, and
workable on a greater variety of systems. The process
will also make Avalon more efficient and scalable which
helps on the server side and the micro client side.
Ubercontainer will be modular, possibly using AOP to
glue together crosscutting concerns.
> I for one don't believe J2ME wants or needs avalon, and I don't feel
> like making big compromises for it. I also think it is a bad
> idea to put
> a strong break on development of phoenix, as it is somewhat
> unsure where
> the winds will take any other setup.
Our primary goal is making development easier. Simplifying.
There are folks who would like to use J2ME, they are new to
our fold and seem genuinely interested. I don't think we should
discount them so quickly. We can (as I demonstrated) make
interfaces that are J2ME friendly and do not block providing
a compatibility layer for A4 components.
> I have a need for ECM2, aka Fortress, so I'd like a release.
> If we don't
> do a release I'll be likely running on a forked nightly.
I think that should be our first code priority.
> I would rather hold on Avalon5 until we have an
> "ubercontainer" in place
> for A4.1.
Honestly, I think the "ubercontainer" would be able to be made
workable with any lifecycle system we want.
> As to ubercontainer....perhaps we should just start with it and see
> where it goes?
There is that possibility too.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
