Re: Failing tinderboxes spam

Hi,

On Sun, Sep 04, 2016 at 03:44:40PM +0200, Jan Iversen wrote:
> But as you say some tinderboxes send these mails very frequently, leading to
> the fact that everybody… just looks at the title and delete the mail, which
> is quite the opposite as what was hoped.

... or filters them away.

And indeed the volume of tinderbox mails is a problem, but fixing them requires
work. Anyone volunteering for that?

Currently, tinderboxes independantly send mails on every failure. This is
unfortunate for multiple reasons: 
- one simple typo will break ~all tinderboxes and spam a lot of folks, often
  after the original issue is even fixed already.
- a misconfigured tinderbox will spam a lot of folks again and again.

I, for one, filter the tinderbox mail away completely and dont have any hard
feelings against others doing the same[1]. Instead of that I either use gerrit or
look at http://tinderbox.libreoffice.org/MASTER/status.html some 15 minutes
after pushing. The tinderbox email setup was a suitable solution in 2010, when
the project started, but it is much less so.

Making the tinderboxes send a summary in regular intervalls would be an
improvement, but not much -- and actually,
http://tinderbox.libreoffice.org/MASTER/status.html is hilariously ugly and
clunky, but still a lot better than any email.
 
So instead of trying to "fix" tinderbox emails, I would suggest to put emphasis on:
- using more gerrit[2]
- have breakage notifications on channels that are suited to realtime. That is
  IRC -- and possibly twitter.
- have a webstatus like http://tinderbox.libreoffice.org/MASTER/status.html,
  but less clunky and ugly, so it might be used more. Instead of using
  something homegrown, building on existing CI tools should be prefered (e.g.
  unless there are very, very good reasons, Jenkins because we already use that)

> It sounds simple to make a marker of the last mail, and then discard further
> emails for 12 hours.

_Iff_ one tries to fix email, instead of moving to more suitable communication
channels, instead of reducing to 1 mail every x hours, it should be restricting
to mails to state changes (that is: only mail when a build changed from green
to red, not when it stays red). Then again, using existing CI tools like
Jenkins likely simplify that too -- so they should be considered for tracking
tinderbox status before writing yet another custom tracking IMHO.

However, in the end, this is just my two eurocents and ultimately Doers Decide. ;)

Best,

Bjoern

[1] I assume most regular contributors have filters setup, thus the spam hurts
    new contributors harder, which is very unfortunate.
[2] This alone should be the best way to reduce the spam. However, the problem
    here is the victims of the spam often arent those that break the build. So the
    incentives are off.