Subject: Re: [Boost-docs] Decoupling documentation builds from release management
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-12-11 17:07:26
On Thu, Dec 11, 2008 at 11:40 AM, John Maddock <john_at_[hidden]> wrote:
> 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
>>> 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.
Hum... Could you be a bit more explicit about that?
> * The build log available online.
> * The inspection report for the build available online.
The automatically run release inspection report runs after the
snapshot upload, in the same directory tree. So it is reporting what
would actually go into a release. So if I understand your comment, we
are already covered there.
> 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.
This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:40 UTC