Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 7474 invoked by uid 500); 19 Feb 2003 04:11:39 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 7463 invoked from network); 19 Feb 2003 04:11:39 -0000 Subject: documentation in separate cvs module or block From: David Crossley To: cocoon-dev@xml.apache.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Feb 2003 15:11:44 +1100 Message-Id: <1045627908.21242.12151.camel@ighp> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Changing thread name for this new subject. Was: Re: closing cocoon-docs? (was: Cocoon Project Report) http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104557472909525 Diana Shannon wrote: > Steven Noels wrote: > > > > On the subject of a separate CVS repository & getting rid > > of branches for maintaining versions of documentation, this > > is a personal feeling. For developers who want to maintain > > documentation, checking out a separate module isn't a big > > burden, and it would also allow us to give > > pure-documentation-people CVS commit access. We talked about this part of the issue before. Anyone who is working on documentation will also need to tweak other files in cvs, especially javadoc comments inside java source. So they need access to all of Cocoon cvs. > > I think splitting out things will provide people with a > > cleaner (less daunting) work environment. If we separate the docs, then how will the effort proceed to create generated documentation direct from the java source. > I find it a PITA to have to update my HEAD **and** release cvs > branches for simple document updates. It's frustrating to have > doc updates dependencies on a HEAD branch that doesn't reliably > build. I think a separate CVS branch/block/module would be a > definite improvement of the existing situation, but I still think > Wiki should remain the way a majority of people contribute/patch > docs. In fact, I think we should consider moving all existing > Cocoon docs straight to Wiki, so people can patch them there. > I proposed it early, when Cocoon's Wiki started, but I backed > off, given the fact it looked like a way to run around Forrest -- > which I didn't want to do. However, now with Wiki's increasing > integration to Forrest (and Steven's ideas of converting wiki > docs via site.xml or similar), it makes increasing sense to me. Will people be able to do both ways - traditional patch/create xdocs in cvs, or via the Wiki? Online editing might be okay for people in well-connected countries. However, for the rest of us, working online via dial-up modem through a clumsy web interface is not productive. We should take this one step at a time. We seem to be falling into the old trap of dreaming up new tools every time that the documentation subject arises. --David --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org