In an attempt to reduce the overhead for the people starring the tree, would it be possible to add email support to tinderbox so that a user can receive emails when the tree changes? Another option, if email functionality is put in place, is to create a newsgroup or RSS service that collects all of these changes that developers, sheriffs, and others can subscribe to.
Component: Tinderbox → Release Engineering
Product: Webtools → mozilla.org
QA Contact: tinderbox → release
Version: Trunk → other
Doesn't firebot do this?
(In reply to comment #1) > Doesn't firebot do this? Yes, any of the mozbots can track tinderbox changes, but I wonder if there is a way to bridge the gap between IRC and a developer's inbox or feed agrigator. The problem is that developers can only monitor the tree so long after they commit a patch. If emails are sent out, then the developer only has to monitor their inbox which is a lot easier than tracking changes in IRC or in Tinderbox itself.
could firebot be taught how to send email?
(In reply to comment #3) > could firebot be taught how to send email? In theory, yes. I would add it to the main mozbot core, if we did. But I don't know if we want to add more overhead to the bot. I would wonder if this belongs more in the server core than the bot core. If we put it in the server core, than it will occur more quickly, and it wont depend on firebot being connected to irc.
Cc-ing Wolf for his views on adding email support to firebot.
I think this has come up before. Having mozbot e-mail a specific address (such as a newsgroup or ML) for a specific tree changing states, that would be OK. (Though the interval would probably take some figuring out.) (Mozbot already has basic e-mail support, its just only used for e-mailing the admin on connectivity errors.)
Having a mailing list would probably not be a bad idea; however, what form do we want these emails to take? I don't know how much information mozbot actually collects from tinderbox, and if we want anything more than an "it's broken" email, mozbot would possibly need to collect more data. Also if another service is used like an RSS feed, then if a build is starred it noted as such in the entity itself. Perhaps, it's not an email service we need, but an up to date list of errors that have not been starred. The tools that currently use all are centered on current tree state. If we created a web service, which could send emails and track tinderbox, then it would likely solve this and a lot of other problems. My personal view, and reed agrees with me, emailing is not mozbot's purpose, but if that is the most simple or functional solution at the moment, then it would be fine for now.
(In reply to comment #7) > My personal view, and reed agrees with me, emailing is not mozbot's purpose, So what's your assertion about how this should be fixed then? Should releng be running similar code to mozbot on a releng machine and sending the output to e.g. dev.tree-management? How does mozbot currently gather tree state information from tinderbox? How do we reconcile this with rando-orangeness, i.e. how do we avoid spamming people with irrelevant information thereby causing them to ignore it?
(In reply to comment #8) > How does mozbot currently gather tree state information from tinderbox? It asks for the tinderbox quickparse URL on an interval and compares changes. http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&quickparse=1
My recommendation would be to add email support directly to tinderbox. Perhaps in the script that scrapes/interprets results. For the random orange, perform checks against a configurable list of regular expressions, and if it is not random orange, send an email to one or more emails. For simplicity, I would have it send to one email to one mailing list that developers can follow, and have the address hard-coded in the file, so no new configuration options (except the random orange list) need to be created.
We're looking to replace tinderbox with another application, which will support logging and a history.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.