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.

http://qpid.apache.org/components/programming/book/index.html
http://qpid.apache.org/books/trunk/Programming-In-Apache-Qpid/html/index.html

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
httpd.conf.

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


Mime
View raw message