cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: [proposal] Cocoon documentation system
Date Tue, 18 Jan 2005 10:28:48 GMT
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 brutus.apache.org 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.

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

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. IMHO, the documentation issue is only editorial, not 
technical. The only logistical issue we should address is merging the 
xdocs with the Wiki.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


Mime
View raw message