On 21 April 2010 06:23, Santiago Pastorino <spastor...@gmail.com> wrote:
> 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. > Santiago, Now, that's a really good idea. Anuj @andhapp > > On Tue, Apr 20, 2010 at 9:35 PM, Federico Builes > <federico.bui...@gmail.com> wrote: > > On Tue, Apr 20, 2010 at 7:21 PM, Chad Woolley <thewoolley...@gmail.com> > wrote: > >> On Tue, Apr 20, 2010 at 2:56 PM, Jeremy Kemper <jer...@bitsweat.net> > 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 rubyonrails-c...@googlegroups.com. > > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@googlegroups.com> > . > > 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 rubyonrails-c...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- Anuj DUTTA -- 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 rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
