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. _______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
