See PHI676. An install reports a haunting by ghosts. Spooky!

See PHI647, which requests minor improvements to the mail delivered under "Require Secure Mail".

See PHI649. The file path typeahead in repositories can be difficult to use when your repository has a lot of long paths which all start with /path/to/some/actual/directory/with/source/in/it/com/java/oracle/.

Some of this moved forward into T13151.

When comparing diff 1 to diff 2, hide all files which have not changed [and have no {old/right/undone} inline comments].

An install would like a way to filter commits by a particular branch, plus normal filter criteria.

Some of this moved forward to T13137.

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

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

Yeah, I'm looking at here, assuming it's ahead of last release.

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)?

You could maybe leave the element off unless it is a larger change. I think my concern here is seeing it on every revision becomes something extra I have to mentally process, but if the intent is to either help show small changes, or large changes, it could just be visible in those edge cases. In those cases at least, the element provides context as to why it's shown at all vs. all the time?

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

I feel your instincts are correct, this information isn't useful in a list form and shouldn't be included. You could make the argument to include it in a hovercard, or bring it into the header on the diff page, and I think those are both fine. Outside of that this seems mostly geared towards avoiding code review, a practice I don't think is well aligned with the overall product goals.

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.

In T13130#238582, @epriestley wrote:

Offhand, two possible issues with that:

• At least one install has an enormous number of packages (tens of thousands? Hundreds of thousands? Seventy-two billion?) and the minimum cost for a package is much, much smaller than the minimum cost of a Herald rule. If packages actually created Herald rules this install would probably explode.

13,636.

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