cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [proposal] Cocoon documentation system
Date Tue, 18 Jan 2005 18:31:41 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.

Very true... and cocoon (then forrest, then lenya) were seeded by me 
with the intention of changing that. 6 years later, still no chance.

I think it's time I step down and let somebody else do it because, 
honeslty, I think I suck at doing that :-)

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

I hear you, but there is a difference now: granular SVN authentication. 
You can "sandbox" your documents and you are guaranteed that no trojians 
will get in your code. This was not possible with CVS... well, it was, 
but it was a pain to convince them.

The problem was to try to convince them before having something running. 
Since the Gump PMC controls brutus, and brutus is already not considered 
safe, we can do whatever we want there, including having our own svn 
repository for docs.

But more than anything, we need something working!

> and b) whether the 
> technicalities of a secure webapp which is tied to the ASF web of trust 
> (keys, certificates) will get solved properly.

yeah, don't hold your breath.

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

the fact is, *we* don't need that.

brutus is not super-secure, but it's, IMO, secure enough for content. I 
mean, if you have an "edit this page" link on the page itself, people 
will not see defacing as a problem with the apache web server 
security... we are long past that which was the entire point.

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

I agree and disagree at the same time.

There would be no wikipedia if it wasn't easy to use.... and we would 
have better docs and less wiki pages, if it was easier to edit the docs 

> The only logistical issue we should address is merging the 
> xdocs with the Wiki.

The day our documentation infrastructure is successful is the day the 
cocoon wiki gets zero activity.


View raw message