Page MenuHomePhabricator

break apart Publish/Notify repo setting
Closed, WontfixPublic

Description

We have a fancy batch compute thingy that runs jobs. The details are not important but there are hundreds of jobs and people (not necessarily just Engineers TM) spend their days updating them or creating new jobs to try things out. The job storage is backed by git but this is more of a backup and record of changes then an indication that the jobs are treated as source code. Some of the changes are machine generated (jobs making jobs) and some people just hit 'save' a lot.

Even though this is noisy-idiosyncratic-psudo-backup isn't really 'source code' it is convenient to syn the repo into phabricator so people can query it and run herald rules on it (ex: 'email me for changes made to IMPORTANT_JOB'). However the volume of noisy changes obliterates the signal:noise ratio on /feed. Breaking apart the Publish/Notify settings would (I think) let people write their fancy herald rules but keep /feed useful.

Event Timeline

cburroughs updated the task description. (Show Details)
cburroughs added a subscriber: cburroughs.

I think this use case is reasonable-enough. There's no technical or product reason that the options need to be combined, use cases for separate options were just flimsy/nonexistent the last time this came up IIRC (I think I have an "I'll separate them if anyone has a reasonable use case" comment buried somewhere).

Using Git to store high-volume non-source-code things is probably often not a great idea, but I think there's enough grey area here that not all of the use cases are categorically bad. (I believe Facebook built some kind of Zookeeper-on-Git thing around 2011-ish which was averaging several commits per minute at some point and not exploding yet; even if it was ultimately moved to a more suitable store, it survived for at least a couple of years.)

cburroughs renamed this task from break part Publish/Notify repo setting to break apart Publish/Notify repo setting.Aug 18 2015, 12:21 PM
eadler added a project: Restricted Project.Feb 22 2016, 11:53 PM
scode moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Feb 23 2016, 12:02 AM
cburroughs moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 20 2016, 3:57 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:16 PM
epriestley claimed this task.

I'm going to WONTFIX this since T13277 has generally taken us in the other direction. "Publish" now controls everything (audit, feed, email/notifications, Herald, closing tasks and revisions).

Although the original use case (use Herald, but not Feed, in a repository) isn't outlandish, I think it's too niche for us to support upstream, and I want to try to simplify/reduce the available settings rather than expand them. In theory, we could have separate track/close-tasks/close-revisions/email/notifications/herald/audits states on a per-ref basis, but in practice usage seems to line up pretty well so that 99% of the time you want all of these things to apply to a branch ("master") or none of these things to apply to a branch ("epriestley-tmp-123").

Note that if the repository is hosted by Phabricator, you can still use "Commit Hook: Commit Content" rules: these fire on pushes, which are separate from the discovery/import/read pipeline.

Some sort of "disable feed for particular objects" rule might also be reasonable in the future, but I'd like to see more use cases before pursuing it.