Em 13-09-2009 18:49, Mike Gunderloy escreveu: > On Sep 13, 2009, at 1:38 PM, Rodrigo Rosenfeld Rosas wrote: > > >> I agree for the usual significative changes. But for the cases where >> small rewrites make the code cleaner without changing Rails >> behavior, I >> think opening a ticket for each small improvement that won't affect >> nothing but code readability would stress the core developers... >> > > Rails has a well-established policy with several levels of gatekeeping > for getting code into the project. From my point of view, this is one > of the reasons for the generally high quality of the code: we can be > assured that every code change is reviewed and approved by at least > one core committer who is intimately familiar with Rails.
I am not suggesting this stops being done. My suggestion is that for small patches, there was an open repository so that the core team could review a lot of them at once, before applying. For instance, if one knows deeply about ActionPack, he could take a look at all changes in ActionPack at once and decide which commits to accept. Anyway, that was just a suggestion. > I for one would argue strenuously against loosening this policy. Given that > there have been over 1400 contributors to Rails so far, I think we > have pretty good evidence that this policy is not too restrictive or > onerous. > I think this works great for new features or bug correction patches. But for small changes aiming at code cleaning or correcting method or variable mispellings, this would be too much in my opinion. > If you think your small changes are real wins for Rails, That is the question. I don't know what you mean by "real win". It is too subjective. I give very much importance about code readability, even when the changes are so small... But most won't care about it. Opening a patch to make Rails a little bit more readable would probably make the reviewers angry in the sense that it would be wasting their times. On the other side, if there is some branch aimed to do just that, then one could take a look from time to time in all these little changes at once. Maybe a lot of little improvements could make a "real win", I don't know... > I urge you to follow the established procedures: create a patch, open a > Lighthouse > ticket, lobby for support. That is what I intend to do for supporting a new :full_messages parameter in validations. But I am not talking about this kind of patch. I am just talking about small changes patches that won't affect the end user, but only Rails code maintainance. > If other developers agree with you, your > changes will have smooth sailing and you'll be able to bask in being a > core contributor. But part of what we depend on is the established > principle of "many eyes make all bugs shallow." No one, not even core > members, just changes the source code without a sanity check. > Thanks God! :) > If you're having trouble getting the tests to run, there are several > resources you can refer to: > > - The "Contributing to Rails" Guide > http://guides.rails.info/contributing_to_rails.html > I've already done that as stated in the first message of the topic. But it seems a lot incomplete. There are no references for installing mocha or other dependent gems. It is not explained how to speed up tests. For instance, the kind of patch I mentioned should potentially only affect the railties module. There is no such "rake test" for railties. There is a 'regular_test' task, but it doesn't run because initializer.rb is being required twice for some reason. I also tried following the activerecord tests, but it also fails: ./test/cases/../../lib/active_record/base.rb:1984:in `method_missing': undefined method `silence_warnings' for ActiveRecord::Base:Class (NoMethodError) > - The Pre-flight Checklist put together by RailsBridge > http://wiki.railsbridge.org/projects/railsbridge/wiki/Pre-flight_Checklist > - The setup notes for the Rails CI server > http://github.com/rails/rails/blob/e033b5d037c303a34e0c5aec2b38ec6270f00f86/ci/ci_setup_notes.txt > I've read these links and the only news I found about testing was about the need of the mocha gem (which mention is lacking in the Rails Guides). > - The Contributing to Rails Railscast > http://railscasts.com/episodes/113-contributing-to-rails-with-git > This was probably the first screencast I watched about this subject, a lot of time ago. > If you're still stuck after working through these various guides, you > could try asking specific questions here or in #rails-contrib on IRC. > So, here you are. Is it just me or someone else is getting trouble running the Rails tests on master branch? I can not run regular_test in railties nor the tests in activerecord (the two that I tried). This is the message from regular_test: rails/railties/lib/initializer.rb:17: It looks like initializer.rb was required twice (RuntimeError) > Or you could join us at the next BugMash (September 26) when > experienced Rails developers and core committers will be available to > help get you over the initial hurdles towards contributing. > I would like to but the BugMash is target only to bugs. I'd prefer to work in the :full_messages patch if it is possible. Thanks for your help, Rodrigo. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
