From ketanpadegaonkar at gmail.com Wed Jun 8 13:36:26 2011 From: ketanpadegaonkar at gmail.com (Ketan Padegaonkar) Date: Wed, 08 Jun 2011 10:36:26 -0700 Subject: [Cruisecontrolrb-developers] Next steps... Message-ID: <4DEFB31A.2070703@gmail.com> 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 . 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 From btguthrie at gmail.com Wed Jun 8 21:21:45 2011 From: btguthrie at gmail.com (Brian Guthrie) Date: Thu, 9 Jun 2011 11:21:45 +1000 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: <4DEFB31A.2070703@gmail.com> References: <4DEFB31A.2070703@gmail.com> Message-ID: 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 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 > . > > 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 > Cruisecontrolrb-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers > From ketanpadegaonkar at gmail.com Fri Jun 10 14:39:34 2011 From: ketanpadegaonkar at gmail.com (Ketan Padegaonkar) Date: Fri, 10 Jun 2011 11:39:34 -0700 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com> Message-ID: On Jun 8, 2011 6:42 PM, "Brian Guthrie" 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 From btguthrie at gmail.com Sat Jun 11 09:07:35 2011 From: btguthrie at gmail.com (Brian Guthrie) Date: Sat, 11 Jun 2011 23:07:35 +1000 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com> Message-ID: 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 wrote: > On Jun 8, 2011 6:42 PM, "Brian Guthrie" 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 > Cruisecontrolrb-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers > From ketanpadegaonkar at gmail.com Sat Jun 11 12:12:32 2011 From: ketanpadegaonkar at gmail.com (Ketan Padegaonkar) Date: Sat, 11 Jun 2011 09:12:32 -0700 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com> Message-ID: 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 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 > wrote: >> On Jun 8, 2011 6:42 PM, "Brian Guthrie" 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 >> Cruisecontrolrb-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers >> > _______________________________________________ > Cruisecontrolrb-developers mailing list > Cruisecontrolrb-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers > From thewoolleyman at gmail.com Sat Jun 11 15:16:49 2011 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 11 Jun 2011 12:16:49 -0700 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com> Message-ID: On Sat, Jun 11, 2011 at 9:12 AM, Ketan Padegaonkar 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... From thewoolleyman at gmail.com Sat Jun 11 15:18:16 2011 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 11 Jun 2011 12:18:16 -0700 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com> Message-ID: On Sat, Jun 11, 2011 at 6:07 AM, Brian Guthrie 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? From btguthrie at gmail.com Sat Jun 11 21:39:24 2011 From: btguthrie at gmail.com (Brian Guthrie) Date: Sun, 12 Jun 2011 11:39:24 +1000 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com> Message-ID: On Sun, Jun 12, 2011 at 5:18 AM, Chad Woolley wrote: > On Sat, Jun 11, 2011 at 6:07 AM, Brian Guthrie 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 From thewoolleyman at gmail.com Sat Jun 11 22:34:51 2011 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 11 Jun 2011 19:34:51 -0700 Subject: [Cruisecontrolrb-developers] Next steps... In-Reply-To: References: <4DEFB31A.2070703@gmail.com>

Message-ID: On Sat, Jun 11, 2011 at 6:39 PM, Brian Guthrie 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. From btguthrie at gmail.com Wed Jun 22 00:54:24 2011 From: btguthrie at gmail.com (Brian Guthrie) Date: Wed, 22 Jun 2011 14:54:24 +1000 Subject: [Cruisecontrolrb-developers] Recent progress Message-ID: 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 From btguthrie at gmail.com Wed Jun 22 01:01:05 2011 From: btguthrie at gmail.com (Brian Guthrie) Date: Wed, 22 Jun 2011 15:01:05 +1000 Subject: [Cruisecontrolrb-developers] Replacing or supplementing Configuration.disable_build_now Message-ID: 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 those other things as well. I'm open to other suggestions but I'd prefer to not ignore it. Cheers, Brian