FYI: there is an RfC running on meta about this migration proposal.

This is serious. May we just undo this mess asap please?

In T277651#6957446, @Ragesoss wrote:

I've now disabled updates for all the 'long' programs, which are ones that have taken longer than 10 minutes for a data update. Many of these which take between 10 and 30 minutes are probably fine, and I'll start re-enabling updates for such pages. I'll be adding a message shortly to indicate when a particular program has updates disabled. For the longest ones, I plan to do more work to limit the time-consuming parts of the process (likely by disabling some features) so that updates can eventually be re-enabled.

I still don't have a good idea of exactly what has caused revision index corruption repeatedly. My best guess at this point is that a database query for one or more of the very long courses can use up all the memory on the server and crash the database while it is in the middle of writing new revisions. I plan to test the systems limits by replicating very long courses on a test server to see if I can recreate and pin down the problem, but it may be a while before the largest ones can be re-enabled. (I suspect that many of these aren't actively needed anyway; some of these very long courses were created one or more years ago and set up to track a set of very active users for 10+ years.)

Thank you so much! We were very concerned this problem could jeopardize our programs, and it is amazing you were able to solve it so fast. Cheers!

Hi . Happy to try it out in portuguese. Not sure what I should do.. .