Berin Loritsch wrote:
We already have a webspace put up for us at http://avalon.apache.org/ and
I think we should take the oportunity to start a migration over to the new
location.

In the WIKI, I have outlined my thoughts on the content of the Avalon site,
and the link can be viewed here:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonSiteChangeProposal

As to the structure of the Avalon Site, I suggest we take the Jakarta
approach.  I am not commiting to any one document generation system, but
rather to how they manage their site:

The "avalon-site" module will contain the XDocs for the main Avalon site
and PMC information.  We might even want to put our generic guides into
that repository.  The look and feel and doc generation code will all reside
in the "avalon-site" CVS module.

Each project will have its own XDocs directory (just like now), with links
provided by the main avalon-site module to the project.  I see having a
total of three CVS repositories:

avalon-sandbox (already done)
avalon-site (can be a simple rename of jakarta-avalon-site and manage the
             change from there).
avalon (all the production code).


All the other CVS repositories will be archived and migrated progressively
to their final maintenance places.

Our releases will use the mirroring approach already outlined.

I think all of these changes will help us reduce the heavy weight of
the Avalon site, and bring things back into a place where we can
look and think like a single community again.

Thoughts?
Having a single place to keep all docs is A Good Thing.

But IMO it's very important that sandbox stuff remains completely separated from the production stuff. This has created enourmous problems and tensions here, and I don't want to see it again.

As for the avalon-site module, we could simply not have it.
Reason:
1) all xdocs are in the "avalon" CVS
2) all sandbox xdocs are in each project CVS dir
3) Forrest generates the site, and Forrest is to be
installed separately
4) we publish the site automatically with the forrest-bot

Less CVS modules, less hastle, less problems.

If we will have other CVS modules for subprojects, they will link between projects via full URLS, so that they can be generated and deployed separately. They have to be separate anyway, or they are not subprojects but part of the main project.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to