In T7408#99038, @Mnkras wrote:

Is this to get rid of deprecated functions/workarounds for older php versions or is this more of "I want to use these newer PHP functions and not worry about this old stuff and backwards compatibility"?

Potential code base changes that could be used after dropping support for PHP 5.2:

Is this to get rid of deprecated functions/workarounds for older php versions or is this more of "I want to use these newer PHP functions and not worry about this old stuff and backwards compatibility"?

In particular, PHP 5.2 has a bunch of known security vulnerabilities.

T7376 added some more information here and would let us produce "You are out of date / your junk is full of local custom code which we don't support" messages.

Took almost 6 hours to apply all adjustment patches (our database is quite huge).
Some patches failed with Row size too large (> 8126) MySQL error. Increasing innodb_log_file_size parameter to 1G helped.
Then failed on phabricator_conduit.conduit_methodcalllog.method with #1406: Data too long for column 'method' at row ... message. Since it is log table, truncating all data solved the issue.

Sorry, wrong phabricator instance, please ignore.

My apologies, the update script wasn't giving any errors, but it does trip up on

This doesn't reproduce for us. Make sure you're following the update guide here:

Does restarting php-fpm help?

Short version, if you want to play with it locally:

The master server would only know about the subservers.

As an aside, I still think it would be nice to send the notification contents rather than just the key (to avoid the extra request to /notification/individual/). Possibly this would be easier with WebSockets than it would have been with Flash.

Does that solve the scaling issue though? Essentially, all Aphlict servers need to be aware of (I.e. store in memory) all clients and all subscriptions. Realistically, I wouldn't expect this to cause any issues for any installs today, but possibly as Aphlict receives more usage it might?

I believe no install will encounter issues with this for a very long time, but we can scale it like this:

We should also probably move it to libphutil and rename it to PhutilTime, although the whole class can't move. This would let us use it in rCORE.

I guess I can fix the super-secret Phacility stuff.

I think this is done now (with the exception of the super-secret Phacility classes)

I think there are more installs using Ponder than projects using Javelin, yes.

Do you think more people use Ponder?

We haven't synchronized changes to rJX for a long time. No one is really using it outside of us and almost all the new stuff is advanced (JX.Leader, JX.Routable, JX.WebSocket) so it doesn't end up at the top of my priority list.

Doesn't Javelin get linted anyways in rJX. That is, do we make a change in /externals/ but not in rJX?

I think that at one point, it just had Raphael (a "real" external). Javelin should get linted. As an easy fix, we could exclude Raphael only.

After my recent diffs, here is the following of the outstanding issues:

Worked. Thanks.

phabricator/ $ ./bin/storage upgrade -f --apply phabricator:20141106.uniqdrafts.php

Okay, I ran adjustment without interrupting and it eventually proceed. However, I got this now.

$ ./phabricator/bin/storage adjust

I suspect that's never useful in this codebase, but could be wrong.

How about adding the $sort_flag to msort as a parameter? It could very well be useful to explicitly sort things numerically?

I've been able to knock out a bunch of these.