T10604 and T4369 do not impact LFS (broadly, they apply only to POST requests, and LFS uses PUT to upload data).

Adjacently, some other parts of the UI currently use the word "enormous" (see https://discourse.phabricator-community.org/t/herald-enormous-check/822). They should be rewritten to use different language (like "Very Large"). We should use the term "Enormous" to mean only "too large to process completely", while the other UI uses it to mean "large enough to partially collapse for viewer convenience".

Also, while it's on my mind, all repositories should probably have this rule today:

See T7789 and D18827. Block Git LFS in some repositories:

See PHI242. SR Latch:

Seriously folks, why make this design decision? I have a user with a long history in my Phabricator install that now cannot get into his account and cannot remember what email address he used to create the account. Under a normal system scenario where I'm Admin, I can just go into his account, tell him which address he used, chastise him for forgetting and not keeping notes and that's it.

D18831 should upgrade this from "horrible fatal" to "reasonable-but-not-ideal normal page". This could still be improved (providing the user more information and taking them into the submodule redirect workflow) but it's normally difficult to end up here without trying.

We have an outstanding support issue (PHI204) about timeouts with large files.

No.

@epriestley Are there any more concrete plans for this "nonblocking" builds? That is something we would like to utilise for one of our projects. Actually quite important as waiting for builds there is slowing us down quite a bit now.

Per above, pushes to staging areas did not push LFS in the past. We should figure out what the state of the world is now and try to resolve it in the upstream, and document anything we can't work around or resolve.

@Grimeh, above, reports that this doesn't work over HTTP. I believe it does, but we should verify this.

As @avivey suggests, the remaining cache can be cleared with:

Anecdotally, Disqus uses Akismet and the hit rate isn't great (I've observed both a high false positive rate, and a high false negative rate).

In T4369#232848, @epriestley wrote:

I don't see any easy way to cheat through $_FILES, though. We could remove it, but we have a nonzero number of users who compile their own copy of Linux and use a window manager that doesn't support drag and drop and disable Javascript and don't believe a monitor should ever have more than 256 colors, so that would leave them out to dry. The conversion also isn't trivial, so even if we want to move in this direction eventually I think it's a significant scope expansion over just building a synthetic $_FILES.

You need to clear some caches too - ./bin/cache purge - but I'm not sure which; And then hard-refresh the in the browser.

Support for Ubuntu 15.10 ended on 2016-07-28.
Did this problem also happen with any later, still supported Ubuntu version (like 16.04) or can this task be closed as obsolete?

This should be fixed by changes in T13024.

This should be fixed by changes in T13024.

Also, in case of "arc land --merge", the merge commit is falsely authored by the revision author.

arc land still prints a warning in this scenario. Is there a way to disable that through .arcconfig? arc land itself doesn't seem to have an option to skip the warning.

(I'm also open to improvements to the XHProf UI in Phabricator if you plan to use that to store and review profiles. Many obvious features like tagging and API access which would make it more usable for handling profiles of projects other than Phabricator itself are likely very easy to implement. But I'm not sure there's tons of room for real integrations, even if you used everything else in Phabricator, and you may imagine tooling which can't realistically exist in the scope of Phabricator.)

For general context:

In PHI231, a more experienced user went through this workflow:

@epriestley what do you think of creating another column in the calendar_eventinvitee table, something like a bool futureStatus so that when we get a list of invitees back, we can check for that flag. I think this would mean a lot of date comparisons (seems inefficient), and I'm not quite sure when to populate event stubs. For example, if the futureStatus flag is set to true for instance 10, and there are stubs for instances 15 and 20, when would 15 and 20 get converted to have the updated status?

Another variation of this is that "Mailing List" users' addresses also can't be edited from the web UI.

Thank you very much!