httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Proposal to move docs to Apache CMS
Date Fri, 04 May 2012 17:54:40 GMT
> From: Tony Stevenson <>
>Sent: Thursday, May 3, 2012 6:06 PM
>Subject: Re: Proposal to move docs to Apache CMS
>Mads Toftum wrote on Thu, May 03, 2012 at 11:26:41PM +0200:
>> On Thu, May 03, 2012 at 05:07:12PM -0400, Rich Bowen wrote:
>> > Ok, thanks to Tony for hand-holding me a little more through\
>> > an explanation of how this would work in practice. 
>> > 
>> > I feel that I was responding with inadequate understanding.
>> > 
>> > So, I'm now firmly +1 on moving the docs to the Apache CMS. There
>> > are still parts of the process that are somewhat unclear to me, but
>> > we can work that out as we go along, I think.
>> > 
>> I'll stick with my firmly -1 for the time being. 
>> Let's get the website into the CMS first, then we can start considering
>> whether that new workflow is workable. 
>> Let's not forget that you're in the middle of several other disruptive
>> projects too - php docs style comments and the carnival colors. 
>> I think the comments will likely be a spam magnet, but casual
>> contributions would be well covered by that. Making them 0 effort to
>> submit.
>> The CMS is a complex beast (yeah, I do know something about it)
>It does not have to be Mads. In its simple form it is a WYSIWYG editor,
>and review page before publishing.  Actually, committers can still commit
>via svn, as they do now.  

Right, well, the thing is without Andre's support this won't ever fly
as *someone* needs to know enough about the current build system to get
it to work with the CMS.  Basically Andre, the CMS is just CI with a simple

web interface.  In a nutshell, you just need to make the changes I outlined
earlier to get the docs builds to work with the CI scripts in place.

I will need to add support in the CMS for the redirection code to work
with the existing docs trees on the live site, but that's just a few lines
of perl.

The advantage of the web interface as there are no additional prereqs-
anyone (even a non-committer) can use the CMS and edit xml source files
using a syntax-highlighted editor in their browser.  Non-committers
are expected to use the CMS webgui to mail their changes as diffs to
the docs list- regular committers can just commit their changes which

will generate a build.  If the build succeeds buildbot will commit
the results back to the staging tree and make them available on the
staging site.  Upon review of the staging site, any httpd committer
can publish them to the live site using either a perl script or thru
the cms itself.

Using the CMS should be a win-win situation: you only sacrifice whatever
advantages there are of having the build artifacts alongside the sources,
but you get a standard system for building all changes and checking those
back into a separate repo.  Casual editors of the docs do not need to read
ANY documentation on how the build system works or even know where the sources
live in svn- they just use the web interface and let the CMS's systems
worry about all that stuff.  People building for non-CMS targets can continue
to do so, be it to generate CHM docs or for bundling into a release (assuming
they don't want to directly use what's already available on the live site).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message