Signal vs Noise?

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? :slight_smile:

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 :slight_smile: 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.