qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@apache.org>
Subject Re: What is the intended process to publish trunk docbooks to the Qpid website?
Date Fri, 17 Jan 2014 12:45:32 GMT
On Fri, Jan 17, 2014 at 5:46 AM, Keith W <keith.wall@gmail.com> wrote:
> Hi Justin
> I tested your extensions to site's make gen-release (which you
> committed at rev 1556392) on an Ubuntu 12  box (like Apache's
> buildbots)  with the dependencies described in the README and
> encountered no difficulties.  The site trunk documentation renders
> correctly.

That's a nice surprise!

> I have a couple of remaining questions:
> 1. For buildbot integration we will need a mechanism for buildbot to
> determine if there is work to be done (i.e. a test before it invokes
> make gen-release RELEASE=trunk && make render).
> Most CI systems I have seen use the result of an 'svn update' and only
> go on to call the later build steps if there were changes, but as the
> gen-release target currently takes responsibility for the svn
> operation, this approach won't fit.
> At the moment I think the trigger will need to use a command such as
> 'svn info http://svn.apache.org/repos/asf/qpid/trunk/qpid
> http://svn.apache.org/repos/asf/qpid/proton/trunk' and trigger the
> build only if the reported revision has increased since the previous
> buildbot invocation.  Did you have any thoughts?

The solution you suggest makes sense to me.  However, it doesn't seem
all that difficult to change the scripts to work against a checkout,
either, so I will attempt that.

> 2. scripts/gen-release-books hardcodes a list of books.  The list of
> books we will want to
> publish will vary over time (for instance I expect we will have a book
> for the JMS AMQP 1.0 client).  Is there a way the scripts can change
> to accommodate this requirement?  Presumably, the scripts need to
> remain compatible with previous releases in order to be able to
> republish documentation from older releases.

That's a good point.  When I initially developed the scripts, I wasn't
anticipating a lot of regeneration.  I'll have to make them less


To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message