Re: [Boost-docs] Decoupling documentation builds from release management

Subject: Re: [Boost-docs] Decoupling documentation builds from release management
From: John Maddock (john_at_[hidden])
Date: 2008-12-11 16:40:19


Beman Dawes wrote:
>> Dave Abrahams has suggested that another aspect of the headache cure
>> could be to decouple doc builds from snapshots. I like that because
>> (1) the snapshot can run every day even if there are issues with the
>> doc build, (2) the snapshot can run on a machine that is already set
>> up to support the lengthy doc toolchain, and (3) the responsibility
>> for the doc build could move from me to those actually use the doc
>> build.
>>
>> One way this could work is for Daniel, or someone else intimately
>> familiar with doc builds, to setup a chron job on their machine that
>> would update their working copy, do the build, zip up doc/html, and
>> put it on an ftp site. The snapshot build would download the doc/html
>> file, unzip it, and copy more recent files into the snapshot. It is
>> easy to set that up such that if some part of the process fails, the
>> snapshot simply uses the previous doc/html contents.

Good idea: I'd offer to host the doc build, but I don't have the cpu-cycles
at present :-(

One thing that we've lost since MetaComm stopped doing this, is the
automatic redirection from the "stub" docs that are in SVN to the latest
generated docs online. So ideally we should have:

* The latest build hosted somewhere within the boost.org domain so that we
can change doc-testers/builders without disruption to the SVN HTML
redirection code.
* The build log available online.
* The inspection report for the build available online.

One thing I'd also like to see is for the PDF's of the individual libraries
to be made available online somewere - I'm prepared to handle the
Jamfiles/scripts needed to actually build these - but again someone else
will have to run the actual cron job.

Cheers, John.


This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:40 UTC