On 24/3/03 9:13 am, "Jeff Turner" <[EMAIL PROTECTED]> 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.
