What is it?

OK

I'm going to merge this into T10004 just so it can be friends with everything else there.

Please take a look at Kimai for some inspiration on how to implement Phrequent. It is very clean and simple and easy to select, start, and stop timing events. Phrequent also needs the ability to track against more than just tasks. For example, our organization would use it to track time against support calls, etc.

But it's the last "application blank state" on a Phacility instance.

DifferentialRevisionQuery looks scary to modernize.

In T10038#150709, @avivey wrote:

Basically all of this also applies to Unit binders, right?

In T10038#150629, @epriestley wrote:

Given how much of a backlog there is here and how slowly I've been able to move through it historically, my initial thought is that there may be no mid-term and T5055 is the pathway forward.

Although T5055 is a large amount of work, it helps us in the long term, while work against these issues directly does not, and I suspect T5055 is more like 10x more work than dealing with all this stuff directly rather than, say, 100x more work.

Basically all of this also applies to Unit binders, right?

One of my first thoughts was similar to @cburroughs', that developing phabricator extensions with the phabricator community could be helpful/fun. However managing that seems like it wouldn't come "for free" and would involve non-insignificant maintenance.

Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github?

Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github? At least one nice thing about having linters upstream is that you get to use phabricator (including arc lint!) to develop them.

Right, but that's because to me master being incorrect is a symptom of all branches being incorrect, which is what the task title and reproduction steps demonstrate.

This tasks describes a deficit in being able to fairly schedule builds, that is not having builds of one project consume all of the available Drydock resources. The response here (and in general it feels like most Drydock-related tasks) was roughly "add more resources". I don't believe "add more resources" is the appropriate or necessarily viable solution to every problem here.