I like that reasoning a lot better than mine, and simply omitting type appears to produce the correct behavior in every browser, at least for this file. I'll try that instead, and we can revisit this after we write a video transcoder in PHP and can offer files in multiple formats.

I can imagine that two <source /> tags might, in some bizarre world, cause browsers to download the file twice when you click "Play", if they're super confused about how to process videos, don't notice that the URLs are the same, and don't hit any caching. But that's a pretty minor bad effect, and I didn't immediately see any kind of bad behavior locally.

Thanks! I wouldn't mind parsing that but I'm hesitant to ask installs to install it -- but it's helpful in understanding that I'm not completely crazy here and that there's at least some basis for "video/mp4" being a quasi-legitimate way to label the video file.

One easy approach we could take is just:

An install is hitting the "large blame does not degrade gracefully" issue mentioned in that task

See PHI594, where a real user had the same human name as an external user from another project.

From PHI604, for completeness, on the newer behavior of "Hide Blame":

validation for the configuration option

Just to make sure we're talking about the same thing, that feedback is true even of the version at HEAD (blue/grey/orange) vs the version that originally shipped (green/grey/red)?

I think there's possibly at least some argument that this element could serve noble goals:

I suppose the approach proposed above gets a questionable result here:

After actually looking at the code, it looks like null can already be returned and works, it's just kind of wrong for some objects (like Dashboards) because they really do have a default policy -- it's just hard-coded.

See PHI612 and elsewhere; using "Take action [the first time this rule matches]" isn't always obvious but is usually a better fit than "When [ thing is created ]" and interacts much better with drafts.

A 600MB patch should not take 3 hours to encode. We should reproduce this and fix whatever the problem is (buffer appends or otherwise), or clearly document why we actually can't fix it.

I'm going to tentatively put this (the Phriction rule, specifically) into T13130 for this week although I'm not sure how much work getting getDefaultPolicyForObject() to return the root document policy is and maybe that's Unbelievably Difficult. Let me take a quick look at that and you can either run with it or I can pick it up if it's some kind of weird arcana.

Ah, yeah. No idea why I typed "blind" instead.

One option is to write "Herald Rules for Herald Rules".

Offhand, two possible issues with that:

See PHI580. An install would like write API access to object relationships (depends on, fixes, etc). This is complicated, but perhaps plannable, and we may be able to put a reasonable facade with partial support into the upstream.

See PHI592. A diff with 600MB of videos required more than two hours to turn into an email patch, which exceeded the task lease duration and cascaded into various other kinds of problems.

See PHI285. An install would like a way to monitor changes to Herald rules.

See PHI251. This requests an "Ignore generated changes." option for Owners.

As a general update here since a couple installs are keeping an eye on it, I have a big chunk of the "use instance.state for everything" diff written, but some of the caching logic is tricky and I haven't had a solid chunk of uninterrupted time to stare at it in the last couple days so I don't expect to get it out in time for the release this week.

I'm happy to bring either change upstream if you want to do the legwork. We could also move them to a wiki page or something. No option here feels particularly good to me.

After D19384, we'll automatically mark these "phantom" notifications as read when you open the menu to review them:

D19384 cleans this up a little bit and mostly fixes the "phantom unread notification" issue in T8953.