Re: [Proposal:Avalon Site] Take advantage of avalon.apache.org

[Nicola Ken Barozzi]

Berin Loritsch wrote:

From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]

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.

I was thinking along the lines of:

avalon-site -- the general site with PMC and administrativa.
avalon-sandbox -- the code under development
avalon -- the released code.

As for the avalon-site module, we could simply not have it.
Reason:
 1) all xdocs are in the "avalon" CVS

Some of those xdocs aren't Framework related.  The XDocs in there
should be focused on the project at hand.

Yes, but the main project pages should IMHO still be where the framework and new container docs are. We are not an umbrella project, so we have a main site with the main project.

 2) all sandbox xdocs are in each project CVS dir

This is as it should be.  Associate your XDocs with your
project.

 3) Forrest generates the site, and Forrest is to be
    installed separately

Does it?  I could have swarn we have like three different doc
generation things....

This is the proposal...
I asked that we do it some time back but it was refused, but now that even Phoenix has Forrest docs and Framework, we can finally start the last conversion.

 4) we publish the site automatically with the forrest-bot

Less CVS modules, less hastle, less problems.

Understandable.

Oh, BTW: http://forrestbot.cocoondev.org/index.jsp
This is the forrestbot that generates the site regularly from CVS.
Just add a cron script that wgets it and publishes it with the frequency needed, and it's done.

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.

Right.

--
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]>