On Oct 9, 2011, at 4:58 AM, Aristedes Maniatis wrote:

> . Confluence website (maybe one day Apache CMS, but that's another issue)
> 2. docbook docs
> 3. javadocs
> 
> (3) used to be built out of my p.a.o account, but recent changes there has 
> meant that is no longer building

Is it our changes in the Maven build? Or something that infra has done?

> (2) needs some automated mechanism to build and publish. Should that be 
> jenkins (not the most reliable!) and then a p.a.o script to publish to www?


> (1) continues to tick another as is, until I have time to spend on learning 
> Apache CMS, navigating a bunch of obscure Perl, etc.
> 
> 
> As for old CAYDOC, I don't see why we'd want to delete old documentation. 
> That is still useful.

We have 4 versions of the documentation with the wiki process - (a) dynamic on 
Wiki, (b) autoexported on wiki (cwiki.apache.org), (c) cloned from (b) to our 
site, (d) - specially formatted version of (a) in SVN. My suggestion is to 
remove (a) and (b) as we don't need them, but keep the (c) and (d). 

> Google rankings are something else again and easily solved with a robots.txt 
> in our root. I just did that now, wait 60 minutes for it to publish.

http://cayenne.apache.org/robots.txt - this is cool. We do need that (although 
maybe allow 30 for now). But I was thinking more about this one: 
https://cwiki.apache.org/robots.txt (if we delete the autoexported garbage, we 
won't care about it anymore though).


> As soon as the new docbook contains all the documentation from the current 
> Confluence docs, then sure, let's replace the trunk documentation with 
> docbook. We'll figure out if infra want us to publish using Jenkins, p.a.o or 
> something else. I'll go ask there now.

My point is that we no longer need (a) and (b) above, but can keep (d) as long 
as we are doing the transition for 3.1 and indefinitely for 3.0 and earlier. 

Does it make sense?

Andrus

Reply via email to