Hey Federico, I was talking with Jeremy Kemper regarding to benchmarks and he points me to try to benchmark an existing open source app. For example port redmine or gemcutter to rails 3 (Jeremy already port redmine http://github.com/jeremy/redmine/commits/rails3 but it's from november) and benchmark one of this (perhaps Gemcutter is simpler) with Rails 2.3 and Rails 3.0 and build a comparison. What do you think?.
You can find me on IRC, i'm spastorino if you want we can exchange more ideas and thoghts about this. Best, Santiago. On Tue, Apr 20, 2010 at 9:35 PM, Federico Builes <[email protected]> wrote: > On Tue, Apr 20, 2010 at 7:21 PM, Chad Woolley <[email protected]> wrote: >> On Tue, Apr 20, 2010 at 2:56 PM, Jeremy Kemper <[email protected]> wrote: >> Hi Jeremy, >> >> Yes, good points. I've already talked with Federico offline. I >> believe his original interest was in improving the rails test suite >> itself, and allowing collaboration and submission of results by users. >> >> I think it is mostly orthogonal to the problem I'm tackling - which is >> to have a performant, stable, easily reproducible "production" CI >> environment which runs the main build script >> (http://github.com/rails/rails/blob/master/ci/ci_build.rb) against the >> major interpreters. >> >> I don't want to make the "production" CI environment any more >> complicated than necessary - and adding the variable of user-submitted >> input from random environments would definitely complicate things. >> It's hard enough to get most people to care about the failing CI at >> all - we need to keep it simple, stable, and reproducible. That's why >> I'm taking the approach of a Rails CI AMI which anyone can run on EC2, >> and the generation of that AMI will also be completely automated. >> That hopefully eliminates any possibility of "non-reproducible" build >> failures, which are the bane of any CI system. I've said >> "reproducible" four times, so you get my point :) >> >> However, as long as any improvements/innovations in this area (rake >> tasks, additional/alternative test/benchmark scripts to ci_build.rb, >> etc) conform to basic conventions - stdout/stderr, generated csv/html >> flat file artifacts, and proper return codes - there's no reason we >> can't integrate it into the main CI environment (or any other CI >> environment) in the future. Even if it isn't integrated, the >> information gathered can drive improvements to the main test suite or >> build script. However, I'd prefer avoid calling this work "CI" or >> lumping it into the "CI" effort, for the reasons mentioned above, and >> also because it would be more "user driven" than "continuous". In >> fact, I've already updated the wiki to say "Crowdsourced Rails >> environment compatibility metrics" instead of continuous integration. > > As Chad mentioned, we've been exchanging emails outside the list and > it's been helpful to ground my proposal. Some of my ideas can fall > outside the current scope of Chad's work on a CI platform to build a > pristine copy of Rails everytime but I think we can definately > collaborate on some of the stuff to make sure all this is usable for > the rails-core guys and for the outsider who just wants to see what's > wrong with X revision on his machine. > > My idea is a bit more biased to what Jeremy initially noted but I'll > keep working on it today/tomorrow to send a copy to the ML looking for > input once it's done. > > Thanks for comments guys. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
