llvm dev - Sep 2014 - [LLVMdev] Phabricator sending empty state change emails for Audit

Hi Manuel,

It's been brought to my attention that my usage of the Phabricator Audit
tool  to track which commits have been reviewed is causing a large number of
(almost) empty emails to be sent to the commit authors and anyone else added to
the audit as a reviewer. Presumably there are some state change emails that we
haven't blocked yet (e.g. the 'Accept commit' and 'Resign from
Audit' actions for pages such as http://reviews.llvm.org/rL214709). Could
you take a look when you get a chance? [*]

Just to explain how I'm using it, I have a Herald rule that matches commits
to lib/Targets/Mips and the corresponding test areas. When this rule matches, it
creates an audit, adds me as a reviewer, and sends me an email. I then look at
the audit and either confirm that it has been reviewed, review it, or ask
someone else to review it as appropriate. Once I'm happy it has been
reviewed properly, I either accept the commit or resign from the audit depending
on whether I'm accepting the whole patch or just the MIPS related portion.
It seems that both 'Accept' and 'Resign from Audit' trigger
state change emails even though there's no text in the comment boxes.

[*] By the way, I'm still trying to get approval to submit patches for
Phabricator from our side. Unfortunately, it's taking longer than I'd
like since they have their own unique licence.

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<http://www.imgtec.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140904/3da0ca6e/attachment.html>

On Thu Sep 04 2014 at 10:59:43 AM Daniel Sanders <Daniel.Sanders at
imgtec.com>
wrote:
>  Hi Manuel,
>
>
>
> It's been brought to my attention that my usage of the Phabricator
Audit
> tool  to track which commits have been reviewed is causing a large number
> of (almost) empty emails to be sent to the commit authors and anyone else
> added to the audit as a reviewer. Presumably there are some state change
> emails that we haven't blocked yet (e.g. the 'Accept commit'
and 'Resign
> from Audit' actions for pages such as
http://reviews.llvm.org/rL214709).
> Could you take a look when you get a chance? [*]
>
>
>
> Just to explain how I'm using it, I have a Herald rule that matches
> commits to lib/Targets/Mips and the corresponding test areas. When this
> rule matches, it creates an audit, adds me as a reviewer, and sends me an
> email. I then look at the audit and either confirm that it has been
> reviewed, review it, or ask someone else to review it as appropriate. Once
> I'm happy it has been reviewed properly, I either accept the commit or
> resign from the audit depending on whether I'm accepting the whole
patch or
> just the MIPS related portion. It seems that both 'Accept' and
'Resign from
> Audit' trigger state change emails even though there's no text in
the
> comment boxes.
>
Yes, so far I haven't had time to look into the audit stuff (assuming that
nobody uses it apart from getting automated emails when things happen);
while I am aware that it would fit us really nicely, all the time I have on
phab is kept by keeping the instance alive, syncing phab to mainline,
filing bugs upstream, keeping our own branch of phab working, and answering
people's questions.
I would *love* any help I could get with that :)
> [*] By the way, I'm still trying to get approval to submit patches for
> Phabricator from our side. Unfortunately, it's taking longer than
I'd like
> since they have their own unique licence.
>
I hear you, I just went through the same process; took us a while; one tip
is: if there's anything specific, contact the upstream phab guys about it
(epriestley espeically), they're pretty responsive and trying to help.

>
>
> *Daniel Sanders*
>
> Leading Software Design Engineer, MIPS Processor IP
>
> Imagination Technologies Limited
>
> www.imgtec.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140904/5a6af611/attachment.html>

> From: Manuel Klimek [mailto:klimek at google.com] 
> Sent: 04 September 2014 10:08
> > On Thu Sep 04 2014 at 10:59:43 AM Daniel Sanders <Daniel.Sanders at
imgtec.com> wrote:
> > Hi Manuel,
> > 
> > It's been brought to my attention that my usage of the Phabricator
Audit tool  to track which commits have been reviewed is causing a large number
> > of (almost) empty emails to be sent to the commit authors and anyone
else added to the audit as a reviewer. Presumably there are some state change
> > emails that we haven't blocked yet (e.g. the 'Accept
commit' and 'Resign from Audit' actions for pages such as
http://reviews.llvm.org/rL214709). Could
> > you take a look when you get a chance? [*]
 > >
> > Just to explain how I'm using it, I have a Herald rule that
matches commits to lib/Targets/Mips and the corresponding test areas. When this
rule matches,
> > it creates an audit, adds me as a reviewer, and sends me an email. I
then look at the audit and either confirm that it has been reviewed, review it,
or ask
> > someone else to review it as appropriate. Once I'm happy it has
been reviewed properly, I either accept the commit or resign from the audit
depending
> > on whether I'm accepting the whole patch or just the MIPS related
portion. It seems that both 'Accept' and 'Resign from Audit'
trigger state change emails
> > even though there's no text in the comment boxes.
>
> Yes, so far I haven't had time to look into the audit stuff (assuming
that nobody uses it apart from getting automated emails when things happen);
while I am
> aware that it would fit us really nicely, all the time I have on phab is
kept by keeping the instance alive, syncing phab to mainline, filing bugs
upstream, keeping
> our own branch of phab working, and answering people's questions.
> I would *love* any help I could get with that :)
Ok then. I'll see if I can figure out what needs changing. Hopefully,
it's a simple fix and I can just tell you/upstream which bit needs changing
and how. If it's trickier then I'll have to wait until I can submit
proper patches.
Can you tell me where our branch is stored? Seeing the changes for Differential
will probably narrow it down a lot.

The amount of help I can offer is a bit limited since my priority has to be the
MIPS target but I'm happy to help with the occasional small feature,
answering questions, etc.