Page MenuHomePhabricator

Hide revision dependency stories from feed/notifications
ClosedPublic

Authored by epriestley on Apr 16 2019, 7:56 PM.

Details

Summary

See PHI1134. Generally, "alice added a dependent revision: ..." isn't a very interesting story. This relationship itself is valuable, but the creation of the relationship is usually pretty obvious from context.

In the specific case of PHI1134, various scripts are racing one another, but I don't think this story is of much value in the general case anyway.

Test Plan

Edited parent/child revisions, no more feed stories.

Diff Detail

Repository
rP Phabricator
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Apr 16 2019, 7:56 PM
epriestley requested review of this revision.Apr 16 2019, 7:58 PM
amckinley accepted this revision.Apr 17 2019, 9:30 PM

I feel kinda similarly about getting a flurry of "added commit to TXXX" notifications that fire in addition to the "bob closed DXXX" notifications. We don't have the infrastructure to say stuff like "only hide this notification if the same action already generated a separate notification of type foo, do we?

This revision is now accepted and ready to land.Apr 17 2019, 9:30 PM

All the same underlying action:

only hide this notification if the same action already generated a separate notification of type foo, do we?

In the absolutely most general case, we can't do this because metamta.one-mail-per-recipient may be off, and alice may only be on the task, while bailey is only on the revision, so we have to send both so that each of alice and bailey get at least one email.

At the moment, both of these emails come from the same task so they could interact, but this may not be true for long.

A half-step might be to just silence "added a commit to" in all cases? I'm not sure that's ever really interesting. That wouldn't silence "closed task X by committing Y", just the cases where a commit gets attached without affecting the task status.

At the moment, both of these emails come from the same task

That is, from the same GitMessageParserWorker task in the task queue, not "from the same Maniphest task" in some sort of virtual sense.

A half-step might be to just silence "added a commit to" in all cases?

Yeah that's fine with me; I was just thinking that users with flows that don't involve Differential revisions might still want to be notified about the attached commit. But that^^ would improve my life, so I'm in favor of it.

  • At least for the moment, fully silence the "commit/task" edges, too.
This revision was automatically updated to reflect the committed changes.