Oh, and this might be useful, but is probably less portable than just using ps.

In D20616#260712, @epriestley wrote:

• The disk can be full, or read-only. Or become full later, including while the daemon is running.
  • Any of these policy/disk state problems can pass any effort we make to test them early, then fail after the process daemonizes, making it difficult to report the failure to the user.

This whole series of changes is motivated by "a PID file was out of date because of a reboot, and we tried to kill some other random process", right? Was there anything else that PID file tracking wasn't doing correctly?

Pick up changes from D20594.

Rename some variables for clarity.

• Renamed classes to remove Configuration
• Created PhabricatorApplicationTransactionJSONDiffDetailView to reduce JSON-related boilerplate
• Found one callsite to switch to PhabricatorApplicationTransactionJSONDiffDetailView
• Implemented getTitle for the various JSON-encoded transactions
• Requested fixes

No wonder I couldn't pass the Facebook eng interview!!

To avoid the extreme case of ComComComJava-itis we could maybe just drop the word Configuration from these classes?

(Also, now that I've read PHI1312, I mind this^^ implementation less since that was the actual support request anyway).

In D20592#260267, @epriestley wrote:

Do you think ( XXX-123 Order More Copier Paper ) is still a reasonable rendering if the parameter is something like ?download=123 and that means "Download Attached File 123" and clicking the link doesn't take you to XXX-123 at all?

If it's the same thing, that seems possibly confusing (two different links have the same visual rendering).

This is just short-circuiting the whole external object lookup process, right? Is it significantly more work to just fix the lookup process to preserve these fragments?

👻

I'm a little worried about a Postel's Law-style HTML parser. Later on I can envision getting more strict about what we accept in the interest of delivering more precise error messages, which might break existing pages that previously worked just by accident. I guess if it ever comes to that, we can write a migration that warns installs about suddenly-malformed wiki pages.

Is it expected that B22956 never completed?

Shouldn't DifferentialTransactionEditor->buildMailBody() get an update to use this new API?

¯\_(ツ)_/¯

This looks good, except as you said, we can't land it until after we remove conpherence_index as well. Should I just approve it now and let it hang around in your unlanded revisions?

If we're trying to drop the MyISAM dependency, don't forget to update the quickstart when we're finished: https://secure.phabricator.com/source/phabricator/browse/master/resources/sql/quickstart.sql$9727

Reading PHI1222; nice catch!