Can we email the pusher/committer when the sherriff makes a comment on their changeset. Bug 608693 is similar, to email upon causing the build to burn.

(In reply to comment #0) > Bug 608693 is similar, to email upon causing the build to burn. That should be bug 608694.

(In reply to comment #0) > Can we email the pusher/committer when the sherriff makes a comment on their > changeset. I guess you mean when anyone makes a comment, not only the pusher? To prevent spam exploits, I would rather do this feature as part of the work to move comments to tbpls own server, in that case we also have the emails of commiter and pusher in our db and don’t need to expose a vulnerable “email as parameter” script.

(In reply to comment #2) > (In reply to comment #0) > > Can we email the pusher/committer when the sherriff makes a comment on their > > changeset. > > I guess you mean when anyone makes a comment, not only the pusher? > > To prevent spam exploits, I would rather do this feature as part of the work to > move comments to tbpls own server, in that case we also have the emails of > commiter and pusher in our db and don’t need to expose a vulnerable “email as > parameter” script. Ah, this is more complex than I thought, though I think you already have the email of the committer at least, as it's displayed in tbpl. In my head, the only person who made comments was the sheriff, and the committer/pusher is the person who needs to be alerted when this happens. You're right that spam complicates this, but I think its a potential problem, rather than an existing one. Perhaps we could only email when a known sheriff comments. That said, its getting a little complex here, perhaps you're right to leave it until a later date.

(In reply to comment #3) > Ah, this is more complex than I thought, though I think you already have the > email of the committer at least, as it's displayed in tbpl. Getting that data is not a problem, the problem is that it is only available clientside. > Perhaps we could only email when a known sheriff comments. That said, its > getting a little complex here, perhaps you're right to leave it until a later > date. Matching the commenter to the current sherrif will be extremely tricky I believe, probably not worth it.

(In reply to comment #4) > Getting that data is not a problem, the problem is that it is only available > clientside. Right. > Matching the commenter to the current sherrif will be extremely tricky I > believe, probably not worth it. Any sheriff would be fine, and I suspect no checking would be fine too. But I think you are right, this is far more complex than I intended, probably not worth it.

Especially since I think you are the only person who ever once expressed a desire to know when someone starred one of their push's failures: pretty much everyone else both wishes to, and quite successfully does, completely and utterly ignore what happens after they type "hg push".