avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [merlin] release preparation request for assistance
Date Wed, 04 Jun 2003 15:24:02 GMT
Stephen McConnell wrote:
> In earlier emails I have posted details of the technical things I wanted 
> to clean up before a release - all of these items are now complete.

things really have improved across the board since I last checked...

I particularly like the way the tutorials are shaping up. Some language 
still very complex in places ("An appliance can be view as an instance 
of a unique named deployment scenario where a deployment scenario is the 
result of combining a particular component type with deployment 
meta-data"), but general usage patterns really are getting clear.

> Some of the actions I think should be taken before a release include the 
> following:
>  1. additional tutorials covering:
>     - custom contextualization
>     - dynamic components
>  2. complete the documentation about the James example
>  3. add documentation concerning the Merlin/Maven plugin

I think complete docs are never a requirement or showstopper for any 1.0 
release. I think merlin docs overall are in rather good shape.

>  3. resolve a manifest generation problem that is currently
>     preventing the proper management of extensions
>  4. either release Excalibur Extension or include a fork
>     under the Merlin project

for the moment, the latter may be the least headache; it's only a few 
classes after all. Just mark them as for internal use only :D

>  5. make sure everything is in sync with the recent
>     Excalibur releases

what I would like as a basic validation test is an example built using 
the 1.0 fortress release running inside a merlin appliance, with all 
shared jars between merlin and fortress actually shared. Should be a 
nice test. thoughts? How feasible would that be?

>  6. tag the CVS

the forrest peeps have a real nice doc about release preperation @ 

which you might want to review :D

>  7. vote on a release

what worries me a little here: who knows enough to vote? The PMC handles 
votes on avalon releases, yet the only person who has made significant 
commits (or patches) to Merlin is you. I've done some trivial cleanup, 
as have Berin and PeterD, and many people have given feedback or 
provided some minor patches, but most of the extensive merlin codebase 
is known well only to you.

This sort-of conflicts with the desire to be able to guarantee 
continuity of any ASF release by having a sizeable developer pool. I 
guess merlin is, at the moment, "in incubation" here @ avalon, waiting 
for that developer pool to arrive. Until that happens, I think it should 
be clear to potential users and developers that merlin does not have 
such a developer pool.

Building and making available a release sort-of sends the opposite 
signal. The message to people asking for a release is then to be 
something like "well, we want more developers to get to grips on the 
code before we do that; feel free to join in". If things are as snappy 
as you say, you are certainly not going to be able to handle all 
"support questions" on your own.

Dunno. I guess one way to accomodate these concerns would be to release 
the files with a '-dev' or '-beta' postfix.



- Leo

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

View raw message