Sure, send me a diff.

PhabricatorFileChunkIterator does the stitching. Basically the flow is like this:

Yep, this is good.

T5378 / D12692 also have some bearing here.

This should probably also wait for (or happen concurrently with / be considered alongside) the repository monogram changes which occur with T4245, although I think it doesn't limit the reasonable syntax available to us very much.

Determining the directories implied by the paths we find and injecting them into the list seems reasonable to me.

Could the server do the chunk stitching and stream the response to the client, rather than fetching it all up front?

Another alternative would be to mangle the commit message more heavily and strip out the fields we believe we can parse. So instead of showing something like this:

I think that would leave us with only two potential scale issues:

A possibly easier approach is to let the user just get an HTTP URI for the download (i.e. a normal, non-Conduit URI) and then call it in a standard way. Maybe by adding a needDownloadURIs parameter to file.info (or waiting for T7715 and adding it to file.query) -- the links are slightly expensive to generate because we have to do one-time token writes so it's probably better not to generate them by default.

Someone else ran into issues with Rocket Loader too, although everything broke completely for them in Chrome (although fine in Safari).

Yeah, I'm fine with putting a global lock on this. You shouldn't really ever be running it on multiple hosts simultaneously (in the best case, this just slows you down by running the slow checks in adjust multiple times), but it's dangerous enough to explicitly prevent.

You can also whitelist MIME types in files.viewable-mime-types as a workaround.

See also T9161. You can use ./bin/mail volume to see how much mail people are actually receiving.

I can't reproduce the capital letter issue.

Presumably, he or she has a good reason for putting this policy in place. I'd recommend talking with them about it. Maybe they haven't thought about this case.

the people that should respond to those comments don't get notified

Couple of very minor hiccups with notify not having a completely clean deploy since it doesn't get pushed/expanded very often and was a bit out of date, but should be fixed now.

I've updated lb, alb and clb and the respective domains are now serving updated certificates.

I can't reproduce this. Here's what I did.

Either is fine.

I don't think we need to auto-generate (and think it's slightly desirable not to -- I don't think we can do anything reasonable most of the time, and it will tend to make it harder to find a good alias when you actually want one if we do).

I do think we can get rid of this page now.

Some discussion in T7053. Mostly, I think it's just a ton of work to fix a problem that I think frequently (almost always?) boils down to users being out of their depth with server administration tasks.

So the CLI said "Go to this URL: XXX" and they didn't do that and instead went somewhere else that they remembered seeing before with the same name?

I think I'm just going to remove this check. The primary goal was to reduce support costs related to users not restarting daemons after changing mail config, but I think the net cost of users hitting it is larger than the net cost of users not restarting stuff was.

How did they end up there?

4spoopy6me

le doot

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Does committing as botusername <anything@anything> definitely not work?

D14390 introduces "ApplicationEditor", which includes more race-resistant controls for editing things like projects and subscribers. In effect, this should merge edits of these fields correctly in all cases where there are no conflicts. Here's an example:

I think this is exceedingly mild/theoretical.

Can you give me a specific scenario where this would be useful?

Upgrade to fe7d8c2.

This same problem exists elsewhere throughout the app.

@chad, do you have any general ideas on what this might look like offhand? It would be good to get a rough first iteration of a direction while I'm tackling ApplicationEditor since all the "generic batch editor" stuff will happen at some point in that process.

Let me get a little further with ApplicationEditor and throw a couple of reference diffs up here before anyone goes crazy with this, since I might still need to change some APIs.

To reproduce:

Actually I guess (2) already got pretty much fixed in D11340.

There are broadly two issues here:

I'm hoping to get this underway in the short term. Before ApplicationEditor actually gets written, we have a longstanding mess in how navigation menus and actions work with the existing ApplicationSearch stuff, roughly captured in T5752.

Thanks for testing the patch, should be in HEAD now. Let us know if you run into anything else.

Oh, sorry, T2950 was itself merged into T3167. Upshot is that we don't plan to change this in the upstream. See also T8227. I think there's a patch on one of those tasks to hack this in locally, but it will be messy/incomplete.

Can you walk me through what commands you used to do your dump/restore? I can't reproduce this problem, and we routinely dump and restore instances in the Phacility cluster.