<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.ruby.cruise-control.devel">
    <title>gmane.comp.lang.ruby.cruise-control.devel</title>
    <link>http://blog.gmane.org/gmane.comp.lang.ruby.cruise-control.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/325"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/324"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/323"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/314"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/313"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/299"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/296"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/294"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/293"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/288"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/282"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/276"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/269"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/264"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/248"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/243"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/242"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/240"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/232"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/226"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/325">
    <title>Some updates,and a couple of test requests</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/325</link>
    <description>&lt;pre&gt;I did some work today to try to fix Cruise daemonization. Everything
looks ok to me on my Mac and Ruby 1.9.2 but I'm having trouble
installing and running JRuby locally. If others could take a poke at
this I'd greatly appreciate it.

Also, as far as I know, we don't need or use anything in the daemon/
subdirectory now; we're relying on Rails' server daemonization, the
killtree script, and straight-up kill to do the work.

The init.rb#stop_server method is using kill -KILL rather than kill
-INT, which is what I'd prefer, because shutting down the process
using -INT while the server is daemonized in Prod mode seems to cause
an infinite loop that I haven't locked down yet. Doesn't seem to
happen in dev mode.

Builders are now creating and cleaning up their own pid files, rather
than Platform creating the pid files at builder start time (and
getting cleaned up, well, never). If someone could explain why Cruise
is creating and using both .pid files and individual builder.lock
files that would be extremely helpful&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-07-03T06:37:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/324">
    <title>Replacing or supplementingConfiguration.disable_build_now</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/324</link>
    <description>&lt;pre&gt;Hi all,

Recently the number of things that the dashboard UI can do with your
builds has expanded a bit; you used to just being able to trigger
builds, but now you can add and kill them as well. So far we've been
using Configuration.can_build_now as a catch-all for these features
(when we guard them at all), but its name doesn't bear much
resemblance to its current usage.

There are a few ways we could go about improving this:

 1) deprecating Configuration.disable_build_now in favor of
Configuration.disable_admin_ui (or something similar)
 2) supplementing Configuration.disable_build_now by adding other
switches, like Configuration.disable_kill_builders and
Configuration.disable_add_project
 3) something else
 4) nothing else

My preference is for #1, because it's simple and captures the intent
of the switch better. #2 is more fine-grained, which might be helpful
in some cases. My suspicion is that you probably don't need that
granularity and anyone looking to disable Build Now probably wants to
disable tho&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-06-22T05:01:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/323">
    <title>Recent progress</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/323</link>
    <description>&lt;pre&gt;Hi all,

Recently we've seen a number of big improvements:

 - new UI has been merged into master
 - a couple of fixes to Git support
 - you can now build and run a cruisecontrolrb gem
 - various improvements to documentation, help files, links, contributors list
 - improved management of environment variables in cruise_config
 - fixes to Bundler support
 - added a Kill Builder button (thanks to the folks at Square for this)
 - removed old and unused files from Rails 2 days
 - tests now pass in Windows (although builds still fail)

We're getting closer to our target date for a 2.0 release, which is
targeted for the 1st of July. Once gem package support is complete, in
the next couple of days, we'll tag and package a release as 2.0.0pre1
and push it out for general usage.

Brian
&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-06-22T04:54:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/314">
    <title>Next steps...</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/314</link>
    <description>&lt;pre&gt;Hi,

Some of you may be wondering who I am. I'm Ketan from ThoughtWorks and 
one of the newest committers to ccrb. I've recently been doing some work 
to run ccrb as a jar (java -jar ccrb.jar) as a simple way to distribute 
ccrb. This is still work in progress. Later worked on fixing the build 
to make it go green 
&amp;lt;http://cruisecontrolrb.thoughtworks.com/builds/CruiseControl/bcc1d7267c145420606bce26006579ba3b17b0a7&amp;gt;.

So far here's what's been done so far(sorry, if this sounds like a 
repeat from previous conversations):

* A brand new ccrb machine - we scrapped the existing machine that was 
running an ancient OS and software which we could not figure out how it 
was setup(thanks &amp;lt; at &amp;gt;AjeyGore and Ranjib Dey from ThoughtWorks 
Infrastructure Support team)
* This has the latest version of ccrb deployed on it(rev bcc1d7).
* Get builder to work for ccrb. There was some work needed to make 
builder to work with rvm.
* Fix documentation generation - this was broken because of an api 
change between rails 2.x and 3.&lt;/pre&gt;</description>
    <dc:creator>Ketan Padegaonkar</dc:creator>
    <dc:date>2011-06-08T17:36:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/313">
    <title>Improving cross-platform support for process creation &amp; destruction (was: Why there was no bundle in CC.rb originally)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/313</link>
    <description>&lt;pre&gt;
Sorry for the delay, folks - was away from the Internet for the last few days.

I've been spiking out ChildProcess
(https://github.com/jarib/childprocess; summary: extracted from
Selenium gem, a cross-platform library to launch and kill processes)
as a platform-relatively-agnostic replacement for CCRB's own
hand-rolled process-management code, and according to that's project's
implementation JRuby on Windows is the only platform that won't yield
a PID after process creation, which might actually create more
problems than it solves if we want to be able to kill live builders.

Questions to authors: Is there a particular reason why the master
Platform.create_child_process method is responsible for creating the
pid file, rather than the child builder creating it on launch? Also,
there's a reference in the comments that appears to suggest that the
builder process tries to hold a lock on its pid file, but that's not
the case in the code - it's using a separate file called builder.lock,
and the existence of the l&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-05-22T09:56:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/299">
    <title>Why there was no bundle in CC.rb originally (and probably still shouldn't be now)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/299</link>
    <description>&lt;pre&gt;Brian:

I see you added Gemfile to CC.rb. Not having external dependencies, binary
gems etc - this was, in fact, by design.

The rationale was that this tool should be easy to install for people who
know nothing about Ruby (because it was used on non-Ruby gigs; probably
still is). Therefore, it should only require Ruby and nothing else (not even
rubygems). Everything else is vendored.

I have a tentative (i.e., not extremely convinced) opinion that it better
remain this way.

--Alex
&lt;/pre&gt;</description>
    <dc:creator>Alexey Verkhovsky</dc:creator>
    <dc:date>2011-05-18T15:46:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/296">
    <title>Problems setting Cruisecontrolrb</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/296</link>
    <description>&lt;pre&gt;
What does this point in Cruisecontrolrb prerequisites means?
The Ruby executable and the associated executable for which SCM you are
using must both be in your PATH.
And how to provide it?
Thanks!
&lt;/pre&gt;</description>
    <dc:creator>masterbloger</dc:creator>
    <dc:date>2011-05-18T07:06:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/294">
    <title>Should Git be the default SCM?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/294</link>
    <description>&lt;pre&gt;Derek Hammer has very kindly offered this patch:
https://github.com/thoughtworks/cruisecontrol.rb/pull/21

This seems like a long-overdue change. Any objections if I merge it?

Cheers,

Brian
&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-05-17T12:24:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/293">
    <title>Recently in CC.rb activity</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/293</link>
    <description>&lt;pre&gt;Recent commits/fixes in CC.rb:

 - Removed TimeFormatter, as it's now obsolete
   (Brian, 193c75f966327186d30613cdf484803cd8e025ce)
 - Removed all usages of deprecated assert_tag
   (Brian, 1ee3e073596ea8de4ca775577d9bb63a72d2afb0)
 - Fix for LH ticket #275 -Add the ability for git's log parser to
handle encoding as part of the commit object
   (Derek Hammer, 611812318bce0b53fa417b3788ef0c807d3eb254)
 - Fix for LH ticket #34 - Incorrect timezone in XmlStatusReport.aspx
(used by cctray)
   (Sudhindra Rao, e409c94169f528b79189852b029cfd89f8d07ed0)
 - Migrated controller tests over to use test "GET /foo should blah"
instead of def test_get_show - more to come in this vein as I attempt
to make CC.rb tests easier to read and interpret
   (Brian, cbed42a90762c23f5e34c561dbbfed759e3b0ed2)
 - Fix for GH issue #18 - ./cruise add command broken by Rails 3 upgrade
   (Brian, 5308ece2963246d6bf1ef329c24fddf21733a3da)
 - Replaced Prototype with jQuery, removed all Rails JS helpers,
removed JS routes that needed to be eva&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-05-17T11:55:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/288">
    <title>Support for Bundler added</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/288</link>
    <description>&lt;pre&gt;Hi all,

I've added basic support for Bundler in commit
2fe5d1b45105fd6f32a091165cdcb608403ac35b. Although I've tried to
adhere to the spirit of cross-platform compatibility, I haven't yet
had a chance to test it in Windows, so if you do so please share your
experience. Here's how it works:

 - If a project is configured with rake_command (or build_command is
omitted) and includes a Gemfile in its root, it's assumed that you
want to perform a bundle install.
 - You can explicitly disable this behavior with project.use_bundler = false.
 - If bundler support is triggered, CC.rb will perform a bundle check
followed by a bundle install if the check fails.
 - Going per Ryan McGeary's advice[1], bundle install defaults to
--path=vendor so as to avoid interfering with other gems installed on
the system. Open to feedback on this.
 - The absolute paths to each project's local vendor and Gemfiles are
passed as arguments to bundle install.

Relevant method is Build#bundle_install. Please take a look.

Cheers,

Brian

[&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-05-10T13:39:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/282">
    <title>cc.rb - high priority issues</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/282</link>
    <description>&lt;pre&gt;Hi Brian,

I think this is the highest priority and something that is a big hurdle 
in using cruisecontrol.rb.

"Add support for performing push-button deploys" - we've faked this
on projects in the past.

and the second priority would be the dashboard - for me personally.


I would like to work on the push-button deploys - once I understand all 
the changes that you have made recently.

-Sudhindra

&lt;/pre&gt;</description>
    <dc:creator>Sudhindra Rao</dc:creator>
    <dc:date>2011-05-07T23:03:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/276">
    <title>CC.rb upgrades and maintenance</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/276</link>
    <description>&lt;pre&gt;Hi all,

I'd like to apologize. I haven't been able to offer the level of
support to the project that it deserves. With this in mind, I've
recently asked for, and been allowed, some time by ThoughtWorks to
update and improve CC.rb. Here's what's happened:

 - Framework has been upgraded to Rails 3
 - Along with that, there's been a lot of configuration, domain model,
and test cleanup
 - Minor aesthetic improvements (look for more here soon)
 - Can add new projects using the UI
 - Now manages dependencies with Bundler (naturally)
 - Lots of old Rails JS helpers replaced with properly-written JS
(framework is still Prototype)

Here's what I know works:

 - All tests pass
 - Cruise command appears to function correctly
 - Can build stuff (which is nice)
 - No major routes or configuration settings have been changed (to my knowledge)

Here's what I'd like to do:

 - Improve TW's ability to provide ongoing maintenance and support
 - Attempt to "do the right thing" wrt. Bundler; I'm open to feedback
on the appropr&lt;/pre&gt;</description>
    <dc:creator>Brian Guthrie</dc:creator>
    <dc:date>2011-05-04T08:16:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/269">
    <title>How about we turn off pull requests(Was: [GitHub] gnufied sent you a pull request fromgnufied/cruisecontrol.rb)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/269</link>
    <description>&lt;pre&gt;How about we turn off pull requests with message asking for
patch+ticket?  Since github doesn't allow non-account-owners to view
pull requests, that's the only way to allow all the collaborators to
help manage tickets/patches.


---------- Forwarded message ----------
From: GitHub &amp;lt;noreply-9UaJU3cA/F/QT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Date: Mon, Jan 25, 2010 at 12:52 PM
Subject: [GitHub] gnufied sent you a pull request from gnufied/cruisecontrol.rb
To: thewoolleyman-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org




gnufied wants you to pull from gnufied/cruisecontrol.rb at master

Body: Can you guys pull in from my fork? I have done two things:

1. Do not load smtl_tls.rb for Ruby 1.8.7.
2. Implement twitter support via plugin.

There are test cases to cover the functionality as well (and thus
shouldn't be a problem to merge).


View repository: http://github.com/gnufied/cruisecontrol.rb/tree/master
&lt;/pre&gt;</description>
    <dc:creator>Chad Woolley</dc:creator>
    <dc:date>2010-02-28T21:26:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/264">
    <title>Disabling disabling of build button?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/264</link>
    <description>&lt;pre&gt;Hi,

I always have problems with the build not button being disabled when
it shouldn't be.  It's something with the ajax call it makes not
coming back, I suspect.  This seems even worse when caching is enabled
for the projects page.

I'd like to add a config flag to optionally disable the build button
auto-disable behavior.  This just means multiple build POST requests
could get submitted, but this isn't a problem, is it?  The server
should ignore them if a build is in progress (I assume this is already
the case, haven't looked closely).

Thoughts?

Thanks,
&lt;/pre&gt;</description>
    <dc:creator>Chad Woolley</dc:creator>
    <dc:date>2010-02-01T05:54:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/248">
    <title>Caching?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/248</link>
    <description>&lt;pre&gt;Has anybody hacked caching into CCRB?  For a public server, the rss
and ccmenu resources should be cached, or else it kills the server
when a bunch of people hit the single mongrel.
&lt;/pre&gt;</description>
    <dc:creator>Chad Woolley</dc:creator>
    <dc:date>2010-01-01T10:39:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/243">
    <title>Couple of bug fixes</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/243</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>Alexey Verkhovsky</dc:creator>
    <dc:date>2009-12-10T18:11:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/242">
    <title>Looking for some light cruise controlhelp</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/242</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>djbristow-p32f3XyCuykqcZcGjlUOXw&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2009-11-24T01:14:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/240">
    <title>Making output limit configurable</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/240</link>
    <description>&lt;pre&gt;Folks,

Shall I go ahead and merge Valentin's patch to make the output size 
configurable? You can find his changes at  
http://github.com/valo/cruisecontrol.rb

Thanks,
Sidu.

-------- Original Message --------
Subject: Re: [GitHub] valo sent you a message
Date: Fri, 30 Oct 2009 01:37:50 +0530
From: C. K. Ponnappa &amp;lt;ckponnappa-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
To: Valentin Mihov &amp;lt;valentin.mihov-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
References: &amp;lt;4ae8b72d2e1e7_17ed3fe199347af04fc-TqxH4ZT+qFGEmiPtDGWxttQT9D6RvEGW&amp;lt; at &amp;gt;public.gmane.org&amp;gt; 
&amp;lt;4AE90456.3040005-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; 
&amp;lt;45448450910290252h17a1c018ife55a1ffa194ca1b-JsoAwUIsXosN+BqQ9rBEUg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;



Sure Valentin, more tests are always welcome. In the meanwhile I will 
get Alexey and others to review and once approved, I will merge changes.

Thanks ever so much!
Sidu.
http://blog.sidu.in
http://twitter.com/ponnappa

Valentin Mihov wrote:


&lt;/pre&gt;</description>
    <dc:creator>C. K. Ponnappa</dc:creator>
    <dc:date>2009-10-29T20:11:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/232">
    <title>(no subject)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/232</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>Alexey Verkhovsky</dc:creator>
    <dc:date>2009-10-05T16:59:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/226">
    <title>A bug introduced by Rails upgrade</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/226</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>Alexey Verkhovsky</dc:creator>
    <dc:date>2009-09-30T00:27:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/225">
    <title>ccrb and mod_passenger(aka mod_rails)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.cruise-control.devel/225</link>
    <description>&lt;pre&gt;Before I look into it I figured I should ask first to potentially save some 
wasted efford.  Has anyone attempted and/or succeeded in installing ccrb 
under mod_passenger on apache?

Thanks,
  -Craig
&lt;/pre&gt;</description>
    <dc:creator>Craig Forbes</dc:creator>
    <dc:date>2009-09-23T14:53:23</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.cruise-control.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.cruise-control.devel</link>
  </textinput>
</rdf:RDF>

