qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith W <keith.w...@gmail.com>
Subject Re: What is the intended process to publish trunk docbooks to the Qpid website?
Date Mon, 03 Mar 2014 09:07:43 GMT
Hi Justin

I haven't heard anything from builds@a.o re, INFRA-7243, so I sent a chaser.

Separately, I raised QPID-5593 to adopt the scripts to publish
jms-client-0-8.  I have a patch for this which I intend to commit
early this week.  I pass it on to you once its is done for a review,
if I may,

I'd like to delete the older copies of the trunk documentation from
site as soon as we have the versions published.


It would be best if we could establish redirects from these URLs to
the new location.  Does anyone know if Apache allow its projects to
have mod_rewrite rules? I'm happy to write the rules if someone can
tell me the process I need to use to  have these applied to the

Kind regards, Keith.

On 27 January 2014 23:58, Keith W <keith.wall@gmail.com> wrote:
> Hi Justin
> The new CHECKOUT_DIR= arg seems to work okay.  Thank you.
> I have raised https://issues.apache.org/jira/browse/INFRA-7243 to have
> a buildbot job created for quid trunk documentation.  I've initially
> requested that the job is created without the commit step so that its
> logs and output can be manually reviewed.
> cheers, Keith.
> On 23 January 2014 11:02, Justin Ross <jross@apache.org> wrote:
>> On Fri, Jan 17, 2014 at 7:45 AM, Justin Ross <jross@apache.org> wrote:
>>> On Fri, Jan 17, 2014 at 5:46 AM, Keith W <keith.wall@gmail.com> wrote:
>>>> 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.
>> As of revision 1560426, you should be able run against a checkout:
>>     % svn update /some/checkout
>>     % make clean [*]
>>     % make gen-release RELEASE=trunk CHECKOUT_DIR=/some/checkout
>> [*] Something I haven't mentioned before: you'll want to call make
>> clean before make gen-* because the gen-* scripts continue to use a
>> shared work dir.
>>>> 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
>>> rigid.
>> It strikes me now that it will be pretty easy to add to the list of
>> books we want to generate and simply keep going if we can't find a
>> book we were expecting.  That way the scripts should continue to work
>> against old versions.
>> Justin

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

View raw message