On Fri, Sep 04, 2009 at 09:55:39AM -0700, Chad Woolley wrote: > > On Fri, Sep 4, 2009 at 7:11 AM, Eloy Duran <[email protected]> wrote: > > Thanks for the feedback, everyone. FWIW, this is not new, build > failures used to go to this list [1]
How about a two stage commit. If CI repo works, then commit to main repo. If not, mail the commiter that the commit failed, while the whole world still has a working build. This is to prevent "broken windows" and the commiter usually has the most information about what could be broken and how to fix, anyway. Or get people pull always via a tag LAST_WORKING_BUILD, but that will be less obvious for many. > However, not fixing the build promptly is a problem, and one of the > reasons I wanted to reinstate notifications to this list. Originally, I was only noting the size. I prefer to read what people write than what machines spit out. > 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. I agree. In this case there are actually two broken widows - the commit and what people pull when they want the latest version. For me, the large-volume machine-generated mail became a third broken window in the way I follow what is going on in rubyonrails-core and how I personally use my mail reader. > 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. The best thing, as pointed out already, would be to prevent these things from ever happening. That aside, I was toying of an idea of a tool like CI, but one that would run continuous integration tests to find the latest set of working gems using or being used by rails (plugins, libraries, etc). Something that could show, for example, if the latest commit to rails or rspec would break the other. An early warning for the commiter about which plugins will be broken and who to mail about what was changed. Any ideas about this? Something already like this exists? Cheers. -- Cezary Bagiński --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
