Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
To: avalon-dev@jakarta.apache.org
Path: not-for-mail
From: Leo Simons <leosimons@apache.org>
Subject: An Avalon Roadmap?
Date: Tue, 07 Jan 2003 12:20:12 +0100
Lines: 87
Message-ID: <avecvs$uk9$1@main.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
Sender: news <news@main.gmane.org>

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?

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. 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!)
- get a better build system in place (centipede, maven or something else)
- convert all docs over to forrest (right?)

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
- write avalon project docs (ie something like the jakarta 'bylaws' but 
shorter and referring to "default" where possible)
- document some undocumented stuff procedure stuff like
	- release plan
	- voting guidelines
	- committer 'internship'

3. Dealing with 'legacy' code
-----------------------------
The Avalon codebase (all cvses together) is big, too big.

- remove stale code that hasn't been released before
- move code not fitting for the avalon project under the wings of 
another PMC, or perhaps to sourceforge
- deprecate ECM (but we need fortress or ubercontainer first!)

4. Work on existing code
------------------------
- do needed maintainance on "Developing with Avalon"
- do some Andy-Oliver-style example-based documentation
- maintainance releases of existing code

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?

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.

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 would rather hold on Avalon5 until we have an "ubercontainer" in place 
for A4.1.

As to ubercontainer....perhaps we should just start with it and see 
where it goes?

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>