cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: [proposal] Cocoon documentation system
Date Tue, 18 Jan 2005 11:49:04 GMT
On 18 Jan 2005, at 11:49, Reinhard Poetz wrote:

> Steven Noels wrote:

>> I'm not so optimistic about a) the chance that automated SVN commit 
>> access using role accounts will be granted, and b) whether the 
>> technicalities of a secure webapp which is tied to the ASF web of 
>> trust (keys, certificates) will get solved properly.
>> That's why I'm steering clear of the ASF infrastructure issue. We 
>> can't possible require the ASF to host a specialized documentation 
>> system, since Cocoon will want to use Cocoon, some Geronimites are 
>> eager of Confluence, old-school folks prefer Anakia, etc etc. I know 
>> there's efforts underway to provide people with machine VMs that they 
>> can play with at leisure, but the infra folks remain severely 
>> understaffed (look at how SVN itself is doing lately), and I'm not 
>> sure whether there will ever be willingness to grant access from such 
>> an untrusted VM to the trusted SVN repo server.
> chicken egg situation ... let's see what's going to be happen ...

Sure. I don't want to hold you back - I'm just thinking out loudly.

>> I think Cocoon needs better documentation, not a new area. ;-)
> meant era ;-)

Ah - sorry.

>> What I fail to understand is your apparent eagerness to get going, 
>> yet you want to focus first on rebuilding things which are already 
>> readily accessible.
> Therefore a concept that works without online CMS. Currently writing 
> xdocs is a pain and the reason why (nearly) nobody is writting docs. 
> Additionally our documentation has to be restructered and partly 
> rewritten because it doesn't reflect how Cocoon 2.1/2.2 can/should be 
> used.

WDYM with no online CMS? The fact that the documentation can be 
exported statically and hosted on the ASF servers, preferably automated 
or at least synchronized with releases? Support for static technical 
documentation and software manuals is exactly what we need to do for 
the 1.3 release (1.2 is planned somewhere in the first two weeks of 

>> IMHO, the documentation issue is only editorial, not technical. The 
>> only logistical issue we should address is merging the xdocs with the 
>> Wiki.
> See above, IMHO this is different.

I suspect we want to say the same thing: the hard part will be getting 
people to work on the documentation (i.e. editorial) and provide them 
with a super-efficient environment to do so. I believe Daisy's editing 
environment is rather efficient, and that it should be quite feasible 
to build a custom publishing application (which can be crawled using 
wget for static renditions) on top of it.

Steven Noels                  
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at  
stevenn at                stevenn at

View raw message