I think it's time to say that the continuous integration, break/fixed notices should be moved to a new list.
It's seriously diluting the important conversations real humans are having. As much as I thoroughly enjoy seeing the reports and status updates. It means little to nothing to me on a "live" perspective, more on a.. if I use this rev of edge, is it stable ( as far as all the oracle, sqlserver, cruisecontrol, etc tests reports are concerned).
Nathaniel.
I had this filter in GMail for a long time now: Matches: to:rubyonrails subject:(“AR/Oracle Unit Test” OR SQLServer OR “Rails-MySQL Build”) Do this: Skip Inbox, Delete it
I’m updating it as new continuous integration setups are made.
No doubt then, seems you are already making procedures to silence it.
I could defiately create the filter as well, but I am sure I am not the only one noticing that the emails on core would have more impact if we didn't have to sift through the commit checks. Especially as more systems are setup in place to ensure that quality is consistently high.
Nathaniel.
Just one question: what name that new list should have? Should it be called rails-core-core or rails-notices-that-nobody-ever-sees? 
Point being, Rails-core is the Rails project team mail list, isn’t it? For continuous integration to have real value, failures in CI should be highly visible, and get fixed quickly. Otherwise, all you have is a perpetually broken build that nobody cares about. Which is not worth the hassle to have.
We can consolidate Oracle and SQLServer builds, once I get that fat dual Opteron box set up with VMs for multiple OS/database combos. Even now, it’s not like Rails build is broken 10 times a day.
+1. I'd like the notices to remain in rails-core
Tom
In fact I've reconcidered and I also give a +1 now CI is awareness and IMO the fact that errors clog the main list prompts to fix them faster
I think it's time to say that the continuous integration, break/fixed notices should be moved to a new list.
Moving them to another list will simply create an error message ghetto which no one checks. I'm happy with them here at present, and their volume is tiny relative to the discussion threads.
+1 from here as well.
I'd rather they be seen.
To think that they would be ignored if they are as important as everyone is making them out to be seems a shame.
It's called organization. Putting a central resource where you can subscribe to - and yes, I did say you can actually subscribe to the list - won't stop people from reading them.
Anyways, was a suggestion to clean things up, but hey. I suppose
people like messy sometimes too I added the filter that was
originally recommended, so my itch is scratched for the time being.
Although I still see value in having a separate list, but hey - better
ideas have been shot down before!
Nathaniel.
CI sending an email means something is wrong that needs to be fixed. Sometimes this is the result of some oversight, like we messed up the Oracle adapter and Michael chimes in with what the issue was and what the fix is. So these emails are usually the beginning of a conversation about how to fix the problem. Having them on the mailing list whose purpose is, in part, to have a conversation about how to fix problems, seems very orderly to me, not messy.
But you're all set now with your filtering rule in place though, so cheers.
marcel
I agree with your observation that having CI build errors go into core seems messy and disorganized. That said, however, I believe that human nature requires that the errors be obnoxious and in-your-face. I'm not very disciplined, and I know that the instant I relegate those kind of errors to a separate list that I have to remember to check, code reliability starts going away - and I suspect I'm not alone in this.
-bd
Like the Rails depreciation warnings.
Moving them to another list will simply create an error message ghetto which no one checks. I'm happy with them here at present, and their volume is tiny relative to the discussion threads.
Completely agree. Rails is all about recognizing human nature. That beauty makes us happy and that happy people are more productive.
It works just as well on the flip side. We all procrastinate, we all ignore that which we can, but we get out of the chair to fix something that is annoying us.
If a particular set of broken reports are annoying you, please get out of your chair and fix it. This list is optimized for those who do rather than those who don't.
Seems that there's broad consensus on that fact, though.