I liked the idea of sending the email to the commit author, as Hudson apparently does as described by Joris. And as I do share concerns about the robustness of the Rails code, I wrote a patch for CruiseControl to be able to do the same: http://github.com/alloy/cruisecontrol.rb/commit/b2be91d12db74d0ac0b8f2d1427453c7f2482470
Cheers, Eloy PS: I didn't have the time to manually test it, as CC doesn't run on 1.8.7, which is what I have, and RVM didn't work for me. I have to leave, so if there are any comments/problems do let me know :) On 4 sep 2009, at 18:55, Chad Woolley wrote: > > On Fri, Sep 4, 2009 at 7:11 AM, Eloy Duran <[email protected]> > wrote: >> I wouldn't be bothered by these CI emails if we'd see one every now >> and then. But nowadays, it seems like every other build is broken. >> That's the real problem here. > > Thanks for the feedback, everyone. FWIW, this is not new, build > failures used to go to this list [1] > > However, not fixing the build promptly is a problem, and one of the > reasons I wanted to reinstate notifications to this list. > > On a large/distributed project like Rails - especially one where many > people run the master branch live in their projects - I believe there > are exactly three appropriate responses to a broken build, in order of > decreasing desirability: > > 1. Fix the failing tests, ASAP > 2. Roll back the change which broke the tests, ASAP > 3. Comment/disable the failing tests, ASAP > > Any other response to a broken build is wrong and lazy, and leads to > broken windows [2]. See my longer rant here: [3] > > Now, it is FINE for the build to go red once in a while, especially > for an open source project like Rails. It is not reasonable to expect > the core team to run the full suite before every checkin, on every > supported database and Ruby interpreter. That would be a waste of > their valuable time and effort, and is why we set up CI to do it > automatically. > > However, LEAVING the build red is NOT fine. Spamming the list and > annoying people is just a symptom of the real problem, which is not > promptly resolving a broken build. Fixing the symptom by hiding the > problem (sending failure emails to a separate list) is > counterproductive, and only exacerbates the broken-window effect. > > Anyway, I've disabled the notifications for now, and the core team has > the ability to disable them anytime they want as well [4]. I didn't > disable them because people complained, but because we just got a new > suite of servers donated to set up an awesome, multi-branch, > multi-interpreter Rails CI environment (thanks EngineYard!), and I > have to complete that migration/setup. > > [1] > http://groups.google.com/group/rubyonrails-core/browse_thread/thread/2b610e77506812c0# > [2] http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy > [3] > http://pivots.pivotallabs.com/users/chad/blog/articles/484-how-you-can-learn-to-stop-worrying-and-love-continous-integration > [4] http://github.com/rails/rails/blob/master/ci/cruise_config.rb#L4 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
