I work on LibreOffice on a very regular basis, and still feel spammed about these mails.
The mails as such are important, because the show we have a problem on master which need to be solved. 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.
It would be nice if any given tinderbox, could reduce the “noise” level, to maybe twice a day (hopefully the problem is solved before that). It sounds simple to make a marker of the last mail, and then discard further emails for 12 hours.
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. 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.
So instead of trying to "fix" tinderbox emails, I would suggest to put emphasis on:
- using more gerrit
- 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. ;)
 I assume most regular contributors have filters setup, thus the spam hurts
new contributors harder, which is very unfortunate.
 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.
LibreOffice mailing list
[hidden email] https://lists.freedesktop.org/mailman/listinfo/libreoffice
On Sunday, 2016-09-04 19:37:54 +0200, Bjoern Michaelsen wrote:
> And indeed the volume of tinderbox mails is a problem, but fixing them requires
> work. Anyone volunteering for that?
I'll try to look after the Calc function test failures on
Linux-rpm_deb-x86_71-TDF and Linux-rpm_deb-x86_71-TDF-dbg during these
conference days. At least we now seem to have some partial indication
what goes wrong.
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack