cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [proposal] Cocoon documentation system
Date Tue, 18 Jan 2005 10:49:56 GMT
Steven Noels wrote:
> On 18 Jan 2005, at 10:59, Reinhard Poetz wrote:
>> I'm not in the position to change the ASF policy and I don't have the 
>> energy to lead all the necessary discussions.
> Sure. Ditto here. :-)
> Besides, the ASF policy is sound, if only optimized a wee bit towards 
> source code governance and the risk of trojans being embedded in our 
> products, rather than documentation sites being hacked.
>>> I prefer Daisy users to make a positive choice instead (look at all 
>>> the features I got!) rather than a negative one (only 85% of my 
>>> requirements are addressed so I'm doomed). Look at how Jira (and in 
>>> the future perhaps Confluence) quickly won lots of ASF users - even 
>>> though Jira is a pig to keep running (Daisy isn't).
>>> I understand that part of the requirements is to comply with the 
>>> existing ASF infrastructure. I've had my opportunity to run a 
>>> non-ASF-infra-resource for two years, and I'm happy that I don't have 
>>> to check server logs of the Wiki anymore. I do hate the current 
>>> documentation system and MoinMoin wiki with a passion though, as its 
>>> split personality is obviously not helping people to produce better 
>>> documentation. So we definitely need one system, which supports both 
>>> Wiki-style grassroots authoring, and a proper software documentation 
>>> CMS. And yes, ASF-compliancy means we should be careful about 
>>> security if we want to run alongside the code repositories.
>>> The only thing I am worried about is that your system will add a 
>>> third option, and that you'll feel the pain in supporting it as I've 
>>> felt with the JSPWiki at times.
>> If I choose Daisy or whatever I could feel the same pain. In all my 
>> projects I've done so far, Cocoon runs pretty stable *and* in this 
>> community there are one or two Cocoon specialists available that could 
>> help out ;-) And of course the plan is to have the webapp running on 
>> ASF infrastructure. First on and I'm sure we get a 
>> secure server that is allowed to access our SVN repo, if tests on 
>> brutus run well.
> 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 ...

>> One thing to add: Of course I don't commit myself to provide a 24/7 
>> support. Maybe my attempt will fail, don't know. Maybe somebody else 
>> will jump in then, I don't know. Maybe it's the start of a new area in 
>> Cocoon documentation, who knows.
> I think Cocoon needs better documentation, not a new area. ;-)

meant era ;-)
> 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.

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


View raw message