This isn't a bug report we can accept upstream. See Contributing Bug Reports for help. In particular:

Those commits are not expected to trigger an audit after D17122 / T10312. The first line of commit messages is now always parsed as a title, even if it begins "Auditors: ...", "Tests: ...", "Reviewers: ...", etc.

PHP7.1 segfaults about a dozen times a day for me, every day, with little apparent rhyme or reason to the segfaults.

We need a neologism for "bad workaround".

(A "workaround" is to not use dashboards, but we'll fix this soon.)

See T12174 -- this is an issue with the new embedded-on-Home dashboards.

Safari / OSX:

I think it would be reasonable to treat this field as remarkup (at least, internally -- probably no bulky UI) so we end up generating a mention on the task. I have similar reservations about making "fixes X" start performing magic in surprising contexts.

Oh, I missed "inline". That reproduces for me. I'll file a separate issue.

Do you have persistent chat open?

This is from a million years ago and I now think we should only respect commit messages. If "Fixes Txxx" works or ever worked in comments, I'd say we should actually undo that.

This is more than two years old and no one else seems to have hit it since then. Declining until we see a modern report.

This report is more than two years old, and we haven't seen other similar reports. If you are still affected by this bug, please file a new request following the guidelines in Contributing Bug Reports. In particular, we need specific reproduction instructions we can follow to reproduce it locally, not just screenshots.

We haven't seen more interest in this since 2012 and this task no longer meets modern criteria for feature requests (see Contributing Feature Requests).

Kicking this out of scope for now.

I think D17298 is probably a good change for Favorites either way (so we don't have a "pin" UI there that doesn't do anything) since it's pretty simple.

Pinning on Favorites has no effect.

You want to use top-most displayable even if the user has two personal dashboards and has explicitly clicked the pin icon on the second one to make it their default item?

You can change the rules for picking a default item in PhabricatorProfileMenuEngine->loadItems() if you want to use different rules.

There isn't a way to un-set a default, or pick a different global default as a default, although you can effectively do either by creating a copy of whatever global item you want to be default and pinning it, except "magic home", which you can't copy. So there are a couple of messy edge cases there but they don't feel too important to me.

If Admin "sets default" on Global, and users have not set a default, the page follow admin default. (I had to set my dashboard as default, as seems to be no way of un-setting a default).

• For HTTP, this is broadly expected in some sense until T4369 is resolved.
• For SSH, this is not expected but the linked file is 1.75GB. Did you encounter this in a more realistic scenario and the size of that file is just for demonstration purposes, or are you trying to store ~1GB binary assets in a Git repository? Git is generally not well suited to serve as a binary asset store. GitLFS (T7789) or possible future changes like T11367 are likely better fits for this use case.

Completely fine to make the engine aware of the viewer running the query, I think we just didn't have use cases for that when this stuff was written.

In 99% of cases, the right thing to do when you see an error in the daemon logs is:

This report is missing version information. See Contributing Bug Reports and Providing Version Information for help. To move forward:

We can only accept bug reports against current versions of Phabricator, as detailed in Contributing Bug Reports. Feel free to file a new report against a modern version, if this issue still reproduces at HEAD of master or stable.

I think D17294 + guidance is maybe good enough?