Not a committer, but: On Mon, 24 Mar 2003, Steven Noels wrote:
> Please cast your vote: > > [+1] creation of cocoon-docs module > [+1] docs should stay in src/documentation of the code tree module(s) (where +1 for docs in src/documentation is for static docs) I sent an email this morning that my stupid MTA bounced back to me. Included it below as I think it's still relevant regardless of the vote, and I'd like to hear what others think about the issue raised. (I hope I get my attributions correct! Multiple snipping and shuffling follows ...) Diana Shannon wrote: > How should we transition? How about: > > 2. Set up separate Cocoon docs repo(s) > - decide what the repo will include (simply docs and/or tools) > - copy both 2.1 and 2.0 docs and associated files into separate > modules/branches/repos. Maintain "old" doc build capability, as > currently functioning, in 2.1 and 2.0. Jeff Turner wrote: > having XML in a separate cocoon-docs module is likely to trigger > the "out of sight, out of mind" syndrome. Diana Shannon wrote: > I hope this isn't true. I also believe it's an overgeneralization. We've > had this debate a lot. I had the impression that consensus is moving > toward supporting a single docs cvs. On Mon, 24 Mar 2003, David Crossley wrote: > We probably need to have a separate discussion on this topic > of "separate repository for docs" to solve it once and for all. So, here it is: discussion on cocoon-docs repository. As I see it, there are the following pros/cons: PRO: 1) Keep all documentation in one place (rather than split across two repositories as now), optionally with tools required to build it. Keeps documentation concern separate from code. 2) Allows people to work on documentation without needing a copy of Cocoon CVS (which implies optional cocoon-doc-only committers, although I'm not sure if this is good/required). Focuses attention on documentation as an entity. 3) Allows merging of 2.0/2.1/... documentation into a single base (not possible if documentation is kept in version-specific code repository). CON: 1) Out of site, out of mind. If it is split, will developers forget to update the docs? 2) If you checkout the code, you don't get a copy of the documentation. In my mind, pro 3 is enough to swing it, but I'd like a solution to con 2 as it worries me. Perhaps the answer to con 2 is to include the static snapshot not within cocoon-docs but within cocoon-2.0/cocoon-2.1? So then you get a copy of the software with a static copy of the docs, and can check out doc cvs if you want to build it dynamically? Thoughts? Andrew. -- Andrew Savory Email: [EMAIL PROTECTED] Managing Director Tel: +44 (0)870 741 6658 Luminas Internet Applications Fax: +44 (0)700 598 1135 This is not an official statement or order. Web: www.luminas.co.uk
