cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [proposal] Cocoon documentation system
Date Tue, 18 Jan 2005 12:20:55 GMT
Reinhard Poetz wrote:
> 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 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.
> 
> 
> chicken egg situation ... let's see what's going to be happen ...

... and if there is no other way, I have ideas to perfectly work around the ASF 
infrastructure without having to forbear from online editing.

-- 
Reinhard

Mime
View raw message