I think a setup warning is reasonable, particularly given that this looks like at least partially a PHP upstream configuration issue (not just one user running some weird custom-built PHP extension they wrote or whatever).

See also T9223, which sort of leads toward an arc build + .arcbuild or some equivalent too.

Nuance currently allows an Item to be in multiple Queues, but I think we don't need to allow this and can simplify things a bit by putting items in exactly one queue at all times.

Closing for lack of feedback.

Yeah, likely just a didRejectResult() issue.

Some stuff like T7580 might be nice to have, but I don't think we have any real blockers here.

le IRC gem

Yeah, we usually try to make these pages have an alternate non-AJAX rendering. Even if users can't generally hit it, it makes debugging a lot easier and is usually trivial, so it tends to pay for itself in the long run.

A lot of the practical cases here are resolved, but the root problem still exists. Basically, the core issue is that an object can say:

the command has potential side effects, or the time of execution is important, and cannot be simply re-run under LC_ALL=C.

D13956 adds a new DarkConsole tab with performance information about request startup. Here's what it looks like on this server:

system default locale

Also not mentioned here is cases where we phutil_passthru() some command like git push. These would be best run in the system default locale, since we echo the output to the user -- unless we also parse it. I think we never do this right now, but I'm not 100% sure.

See also T7339, which is somewhat related.

(Maybe we should modularize profile panels and then just let Ponder stick a stats panel on your profile?)

Yeah, @chad locked this down (I think to stop new users from, e.g., filing "High" priority issues).

At HEAD, I think we've replaced the bar with icons everywhere, and I think we're planning to let different priorities have different icons, so this information will no longer be communicated only through the use of color once that happens (@chad, does that sound right?).

To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini

Maybe I'll take a shot at this before T9132 starts rolling out since that will probably involve touching every /edit/ route in every application, much like we previously replaced every /query/ route for ApplicationSearch.

Ah, thanks. That makes sense.

If you want to hunt those down I'll review 'em, but am generally in agreement with @chad here that this is the minorest of nits.

It's also nice to have the whole current/new title linked, so maybe ideal would be:

I think there are two separate issues here:

Pretty much all the hg stuff uses bookmarks where the git stuff would use branches. This partly makes more sense with Mercurial (in Mercurial, branches are normally permanent and durable, and Mercurial warns you about this when you create one and asks if you meant to create a bookmark instead -- Mercurial bookmarks are more similar to Git branches than Mercurial branches are), and partly Facebook was heavily involved in shaping the Mercurial flows and they use bookmarks.

I've historically thought about this mostly from the point of view of having the $object reach up to the $application and get URIs from it -- since the Application defines the routes -- but maybe that's not really the right way to tackle it, especially since it's hard to generate URIs from routes but relatively easy to generate routes from URIs.

getApplicationURI() only solves this for the first part of the path (although that happens to be the issue here), and isn't available inside the Editor where mail is being constructed. One thing we could do is throw if URIs passed to getApplicationURI() don't route when in development mode, although that doesn't feel amazing.

Yes, the related tasks added a direct way to accomplish this by using Herald rules.

Hmm, okay. In the short term, I think we can bring some equivalent of MavenTestEngine upstream after T5568, more or less as written.

Yeah, maybe a good general question is: does mvn-unit <one trivial test> run in under, say, 60 seconds in any realistic environment? If the answer is "no", maybe arc diff isn't a good venue for these tests.

We could fix the "maven-make can't detect a no-op quickly" issue in arc itself by letting your test engine say "run maven-make unless some other part of the current arc workflow already ran it and hasn't made changes to the working copy in the meantime", since we're fine with assuming that the rest of the world is frozen while you're running arc.

Also, just to check that my thinking is right since I'm not in touch with the Java world, we're really talking about Maven here, not Java in general, right? Maven is just a build tool for Java, not part of the core language? Is it so ubiquitous that it's effectively universal, or is it just the most common/popular tool? How are Maven, Gradle, and Ant related? Is Maven also used for other languages (Scala, Groovy)?

Can you compile the code explicitly, without running tests?

This seems to have completed without incident.

I've added support for dedicated log volumes (see commit above). Only repo class hosts currently have much use for them, although I'd expect to deploy them more widely eventually.

This error handling block is incorrect:

The general plan here is to switch unit test configuration to an .arcunit file by default (T5568). This technically works today but isn't quite ready for use yet.

Yeah, there's no separation of Join/View policies currently.

It is done.

Presuming resolved since D13931 is in HEAD. Thanks for the report!

D13939 will fix T8672, the most immediate cause of high log volumes, but I'm going to hold it until after we cut the release since it also raises the urgency of potential existing errors.

See T9213 for another case of htis.

I folded this into D13939, which also fixes the root problem (hopefully). It ended up with a LiskDAO change so I want to wait until after we cut the stable branch on Saturday morning.