Next steps...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Next steps...

ketanpkr
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
<http://cruisecontrolrb.thoughtworks.com/builds/CruiseControl/bcc1d7267c145420606bce26006579ba3b17b0a7>.

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 @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.0.

Next steps:
===========

I feel the next steps should be to ensure that we are able to cut out a
release(the last one was in mid 2009 - 2 years ago). To that effect I'd
like to propose the following, and gather some consensus around the next
steps.

This is fairly aggressive with the goal being able to cut a new release
without having to stop the line for developing new features. Feel free
to add anything that you feel should go into this list. These dates are
just tentative in nature, we can be a lot aggressive if we feel we're up
for it :)

* 1.5 beta end of next week(17th June)

Cut out a branch for 1.5 work. No new features land on this branch,
anything new goes to the master branch to avoid regressions.

* 1.5RC week after(24th June)

Monitor any feedback around potential bugs that crop up and get them
fixed. Cherry pick everything to master if needed.

* 1.5 week after(1st July)

Cut out a final release. Cherry pick everything to master if needed.

Just my 2 cents. Curious to hear from everyone else.

--
Ketan
http://ketan.padegaonkar.name | http://eclipse.org/swtbot
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

Brian Guthrie-2
Hi Ketan,

I've been tying all of these features to a 2.0 milestone, including
the Java work you've been doing. You can see the milestones here:

https://github.com/thoughtworks/cruisecontrol.rb/issues/milestones

If that's more appropriately tagged as 1.5, I think that's a
worthwhile conversation; I picked 2.0 because I figured enough time
had passed, and the structural changes were significant enough.
There's also some "future release" stuff lumped under 2.1. If you'd
like to add a release date to those milestones, which I haven't done
yet, I think that would be great.

The release dates you've suggested sound reasonable to me. I think the
17th is about as aggressive as I'm willing to go, though, I think.

There are more improvements I'd like to see to Bundler support,
including on that I think needs to happen prior to the release
(arguments need to be properly configurable, for one). I have some
local changes here that I'll push up soon.

We still need proper Windows support. As far as I can tell, there's no
good way to get Nokogiri running there, so I'm planning on removing
that dependency.

Brian

On Thu, Jun 9, 2011 at 3:36 AM, Ketan Padegaonkar
<[hidden email]> wrote:

> 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
> <http://cruisecontrolrb.thoughtworks.com/builds/CruiseControl/bcc1d7267c145420606bce26006579ba3b17b0a7>.
>
> 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 @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.0.
>
> Next steps:
> ===========
>
> I feel the next steps should be to ensure that we are able to cut out a
> release(the last one was in mid 2009 - 2 years ago). To that effect I'd like
> to propose the following, and gather some consensus around the next steps.
>
> This is fairly aggressive with the goal being able to cut a new release
> without having to stop the line for developing new features. Feel free to
> add anything that you feel should go into this list. These dates are just
> tentative in nature, we can be a lot aggressive if we feel we're up for it
> :)
>
> * 1.5 beta end of next week(17th June)
>
> Cut out a branch for 1.5 work. No new features land on this branch, anything
> new goes to the master branch to avoid regressions.
>
> * 1.5RC week after(24th June)
>
> Monitor any feedback around potential bugs that crop up and get them fixed.
> Cherry pick everything to master if needed.
>
> * 1.5 week after(1st July)
>
> Cut out a final release. Cherry pick everything to master if needed.
>
> Just my 2 cents. Curious to hear from everyone else.
>
> --
> Ketan
> http://ketan.padegaonkar.name | http://eclipse.org/swtbot
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

ketanpkr
On Jun 8, 2011 6:42 PM, "Brian Guthrie" <[hidden email]> wrote:
> If that's more appropriately tagged as 1.5, I think that's a
> worthwhile conversation; I picked 2.0 because I figured enough time
> had passed, and the structural changes were significant enough.
> There's also some "future release" stuff lumped under 2.1. If you'd
> like to add a release date to those milestones, which I haven't done
> yet, I think that would be great.

Calling this a 2.0 sounds good to me given that its been a while and
its been a lot of improvements.

> The release dates you've suggested sound reasonable to me. I think the
> 17th is about as aggressive as I'm willing to go, though, I think.
>
> There are more improvements I'd like to see to Bundler support,
> including on that I think needs to happen prior to the release
> (arguments need to be properly configurable, for one). I have some
> local changes here that I'll push up soon.

Theres quite a few improvements that could be made. I'm thinking
things like paths to ruby, rake bundler etc. I'm not sure if we can
push all this into master without pushing the timeframe up ahead by a
couple of weeks which I understand, and am fine with.

> We still need proper Windows support. As far as I can tell, there's no
> good way to get Nokogiri running there, so I'm planning on removing
> that dependency.

Rexml is a good alternative to nokogiri, it's not all that fast, but
we're not doing a lot of XML parsing. So we should be good in that
regard.

- Ketan
studios.thoughtworks.com | eclipse.org/swtbot | @ketanpkr
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

Brian Guthrie-2
Hi Ketan - I've updated the 2.0 milestone on Github with the release
dates you've outlined. I've attempted an improvement at Bundler
support today, under the assumption that CC.rb itself needs to veer a
little bit outside of the mainstream; we're vendoring our .gem files,
and my assumption (which may be incorrect) is that most Ruby projects
aren't currently doing that. Even if they are, they'll need the
ability to turn --local off.

So my proposed solution is a configurable array of bundler_args on
Project. It's not a thrilling solution; feels a bit like a compromise
to me - a little bit more manageable and idiomatic than a plain
string, a little less complex than trying to support full-on args
rewriting. Please, everyone, let me know if this won't work for you,
and particularly if you'd like to handle it a better way.

Brian

On Sat, Jun 11, 2011 at 4:39 AM, Ketan Padegaonkar
<[hidden email]> wrote:

> On Jun 8, 2011 6:42 PM, "Brian Guthrie" <[hidden email]> wrote:
>> If that's more appropriately tagged as 1.5, I think that's a
>> worthwhile conversation; I picked 2.0 because I figured enough time
>> had passed, and the structural changes were significant enough.
>> There's also some "future release" stuff lumped under 2.1. If you'd
>> like to add a release date to those milestones, which I haven't done
>> yet, I think that would be great.
>
> Calling this a 2.0 sounds good to me given that its been a while and
> its been a lot of improvements.
>
>> The release dates you've suggested sound reasonable to me. I think the
>> 17th is about as aggressive as I'm willing to go, though, I think.
>>
>> There are more improvements I'd like to see to Bundler support,
>> including on that I think needs to happen prior to the release
>> (arguments need to be properly configurable, for one). I have some
>> local changes here that I'll push up soon.
>
> Theres quite a few improvements that could be made. I'm thinking
> things like paths to ruby, rake bundler etc. I'm not sure if we can
> push all this into master without pushing the timeframe up ahead by a
> couple of weeks which I understand, and am fine with.
>
>> We still need proper Windows support. As far as I can tell, there's no
>> good way to get Nokogiri running there, so I'm planning on removing
>> that dependency.
>
> Rexml is a good alternative to nokogiri, it's not all that fast, but
> we're not doing a lot of XML parsing. So we should be good in that
> regard.
>
> - Ketan
> studios.thoughtworks.com | eclipse.org/swtbot | @ketanpkr
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

ketanpkr
We may be in a position to apply the '--local' arg to bundler by
checking existence of vendor/cache directory.

Ketan
studios.thoughtworks.com | twitter.com/ketanpkr




On Sat, Jun 11, 2011 at 6:07 AM, Brian Guthrie <[hidden email]> wrote:

> Hi Ketan - I've updated the 2.0 milestone on Github with the release
> dates you've outlined. I've attempted an improvement at Bundler
> support today, under the assumption that CC.rb itself needs to veer a
> little bit outside of the mainstream; we're vendoring our .gem files,
> and my assumption (which may be incorrect) is that most Ruby projects
> aren't currently doing that. Even if they are, they'll need the
> ability to turn --local off.
>
> So my proposed solution is a configurable array of bundler_args on
> Project. It's not a thrilling solution; feels a bit like a compromise
> to me - a little bit more manageable and idiomatic than a plain
> string, a little less complex than trying to support full-on args
> rewriting. Please, everyone, let me know if this won't work for you,
> and particularly if you'd like to handle it a better way.
>
> Brian
>
> On Sat, Jun 11, 2011 at 4:39 AM, Ketan Padegaonkar
> <[hidden email]> wrote:
>> On Jun 8, 2011 6:42 PM, "Brian Guthrie" <[hidden email]> wrote:
>>> If that's more appropriately tagged as 1.5, I think that's a
>>> worthwhile conversation; I picked 2.0 because I figured enough time
>>> had passed, and the structural changes were significant enough.
>>> There's also some "future release" stuff lumped under 2.1. If you'd
>>> like to add a release date to those milestones, which I haven't done
>>> yet, I think that would be great.
>>
>> Calling this a 2.0 sounds good to me given that its been a while and
>> its been a lot of improvements.
>>
>>> The release dates you've suggested sound reasonable to me. I think the
>>> 17th is about as aggressive as I'm willing to go, though, I think.
>>>
>>> There are more improvements I'd like to see to Bundler support,
>>> including on that I think needs to happen prior to the release
>>> (arguments need to be properly configurable, for one). I have some
>>> local changes here that I'll push up soon.
>>
>> Theres quite a few improvements that could be made. I'm thinking
>> things like paths to ruby, rake bundler etc. I'm not sure if we can
>> push all this into master without pushing the timeframe up ahead by a
>> couple of weeks which I understand, and am fine with.
>>
>>> We still need proper Windows support. As far as I can tell, there's no
>>> good way to get Nokogiri running there, so I'm planning on removing
>>> that dependency.
>>
>> Rexml is a good alternative to nokogiri, it's not all that fast, but
>> we're not doing a lot of XML parsing. So we should be good in that
>> regard.
>>
>> - Ketan
>> studios.thoughtworks.com | eclipse.org/swtbot | @ketanpkr
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

Chad Woolley
On Sat, Jun 11, 2011 at 9:12 AM, Ketan Padegaonkar
<[hidden email]> wrote:
> We may be in a position to apply the '--local' arg to bundler by
> checking existence of vendor/cache directory.

Is that safe to assume?  Maybe everything isn't packaged?  Shouldn't
be normal, but I wouldn't want to force any option...
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

Chad Woolley
In reply to this post by Brian Guthrie-2
On Sat, Jun 11, 2011 at 6:07 AM, Brian Guthrie <[hidden email]> wrote:

> Hi Ketan - I've updated the 2.0 milestone on Github with the release
> dates you've outlined. I've attempted an improvement at Bundler
> support today, under the assumption that CC.rb itself needs to veer a
> little bit outside of the mainstream; we're vendoring our .gem files,
> and my assumption (which may be incorrect) is that most Ruby projects
> aren't currently doing that. Even if they are, they'll need the
> ability to turn --local off.
>
> So my proposed solution is a configurable array of bundler_args on
> Project. It's not a thrilling solution; feels a bit like a compromise
> to me - a little bit more manageable and idiomatic than a plain
> string, a little less complex than trying to support full-on args
> rewriting. Please, everyone, let me know if this won't work for you,
> and particularly if you'd like to handle it a better way.

Maybe I missed bundler discussion on another thread, but why not just
default to "bundle install" with no args, and allow a string to be
passed to override args?  Why do we need to pass any other args by
default?
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

Brian Guthrie-2
On Sun, Jun 12, 2011 at 5:18 AM, Chad Woolley <[hidden email]> wrote:

> On Sat, Jun 11, 2011 at 6:07 AM, Brian Guthrie <[hidden email]> wrote:
>> Hi Ketan - I've updated the 2.0 milestone on Github with the release
>> dates you've outlined. I've attempted an improvement at Bundler
>> support today, under the assumption that CC.rb itself needs to veer a
>> little bit outside of the mainstream; we're vendoring our .gem files,
>> and my assumption (which may be incorrect) is that most Ruby projects
>> aren't currently doing that. Even if they are, they'll need the
>> ability to turn --local off.
>>
>> So my proposed solution is a configurable array of bundler_args on
>> Project. It's not a thrilling solution; feels a bit like a compromise
>> to me - a little bit more manageable and idiomatic than a plain
>> string, a little less complex than trying to support full-on args
>> rewriting. Please, everyone, let me know if this won't work for you,
>> and particularly if you'd like to handle it a better way.
>
> Maybe I missed bundler discussion on another thread, but why not just
> default to "bundle install" with no args, and allow a string to be
> passed to override args?  Why do we need to pass any other args by
> default?

I'd like to do this but it doesn't seem to square nicely with the
desire to provide a nice out of the box end user experience.

It speeds things up quite a bit to run bundle check prior to install
(which is what CC.rb does now); those commands share some subset of
arguments, and it would be nice if we could avoid the complication of
requiring them to be independently configurable; there are various
bits and bobs with the full Ruby and Gemfile paths that you have to
get right; installing to --path=vendor seems like a must if you're
planning on building multiple projects on the same box; --no-color
strips out unwanted console color output.

Brian
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Next steps...

Chad Woolley
On Sat, Jun 11, 2011 at 6:39 PM, Brian Guthrie <[hidden email]> wrote:
>> Maybe I missed bundler discussion on another thread, but why not just
>> default to "bundle install" with no args, and allow a string to be
>> passed to override args?  Why do we need to pass any other args by
>> default?
>
> I'd like to do this but it doesn't seem to square nicely with the
> desire to provide a nice out of the box end user experience.

Makes sense.  The only hard requirement should be that all options can
be overridden/disabled - i.e. don't lock in any specific usage of
bundler or options.
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers