cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
Date Tue, 25 Mar 2003 09:14:36 GMT
Pier Fumagalli wrote:
> On 24/3/03 9:13 am, "Jeff Turner" <jefft@apache.org> wrote:
> 
> 
>>On Mon, Mar 24, 2003 at 07:31:39AM +0100, Steven Noels wrote:
>>
>>>In order to get one little step closer to the 'new' document
>>>infrastructure, many of us seek clarity whether we should move docs to a
>>>separate CVS module or not. The benefits and downfalls are largely
>>>known, so let's vote on this and get this issue cleared.
>>>
>>>My own personal bias: don't forget the different Cocoon _versions_ are
>>>now stored in separate modules, too.
>>>
>>>Please cast your vote:
>>>
>>
>>[  ]  creation of cocoon-docs module
>>[+1]  docs should stay in src/documentation of the code tree module(s)
>>
>>Because:
>>
>>- With a separate cocoon-docs module, I don't see how the various
>>code-related files (status.xml, jars.xml) are obtained.
>>
>>- Making a separate doc module kills outright any future efforts to
>>generate docs directly from code (e.g. a component manual).
>>
>>- I think that by default, doc changes should only apply to one codebase
>>(2.0 or 2.1).  There are many differences that are *meant* to be there,
>>that could get lost if 2.0 and 2.1 docs are generated from a common
>>source.
> 
> 
> Folks, do you know that there's the possibility to alias certain subparts of
> a particular CVS repository from another repository?
> 
> Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
> 
> Apache does it already with its httpd-docs repository, aliased to
> httpd-2.0/docs (or something like it)...

Uh, that sounds *AWESOME*!

Could it be possible, then, to restrict access of some committers only 
to the doc module but have commits coming thru the *main* module land in 
there as well?

That would solve all issues at once, I guess.

Stefano.



Mime
View raw message