You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@citi-us.com> on 2002/12/26 17:19:38 UTC
[Proposal:Avalon Site] Take advantage of avalon.apache.org
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?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Leo Simons
>
> I just found the new ant download page. Pretty neat, will
> have to look
> at this :D
>
> OTOH, I wonder whether avalon downloads are a significant part of the
> bandwidth usage :P
Aim big. If we do it right when we are small, we won't have growing
pains (at least as many) when we are big.
> > Thoughts?
>
> go for it! (Except for the giant-cvs-unification, which needs
> some more
> thought an should be dealt with seperately regardless.)
Right.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Leo Simons <le...@apache.org>.
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.
sounds good.
> 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.
sounds good. I wanted to do that ages ago but basically felt the work
wasn't worth the benefit :D
> avalon-site (can be a simple rename of jakarta-avalon-site and manage the
> change from there).
sounds good.
Don't think it matters as far as the site is concerned whether we move
other stuff to other repos as well; rename is good regardless. SoC you
know ;)
> Our releases will use the mirroring approach already outlined.
I just found the new ant download page. Pretty neat, will have to look
at this :D
OTOH, I wonder whether avalon downloads are a significant part of the
bandwidth usage :P
> Thoughts?
go for it! (Except for the giant-cvs-unification, which needs some more
thought an should be dealt with seperately regardless.)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Greg Steuck <gr...@nest.cx>.
>>>>> "Steven" == Steven Noels <st...@outerthought.org> writes:
Steven> Or even better: try and help Jeff and me to make it possible
Steven> to make it easier to publish updates to daedalus:
Steven> - us push-scp'ing to daedalus - you pull-scp'ing from
Steven> daedalus - some role account being set up on both servers
Steven> doing it on a regular basis
If bandwidth is an issue and CPU power is not rsync over ssh is a good
alternative to scp. Especially when content doesn't change too often.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> 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.
Or even better: try and help Jeff and me to make it possible to make it
easier to publish updates to daedalus:
- us push-scp'ing to daedalus
- you pull-scp'ing from daedalus
- some role account being set up on both servers doing it on a regular
basis
Other security-minding suggestions very much welcomed!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
>>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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > 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.
> 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....
> 4) we publish the site automatically with the forrest-bot
>
> Less CVS modules, less hastle, less problems.
Understandable.
> 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.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal:Avalon Site] Take advantage of avalon.apache.org
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>