London hackfest April 2017 - Upgrade performance discussion notes

1. sam's crazy idea

Split upgrade steps (in upgrade.php) into separate files or something, with metadata for each step
Categorise upgrade steps into ones that can safely run before the upgrade downtime, after it, or must run during it.
This would be optional (it tracks if you did it, so if you didn't, you get them during normal upgrade
ISSUES: Some people would still be worried about making production changes even if the 'before' changes are supposed to not affect anything...

Could the upgrade display how long each step took (in the CLI/web output)
Would it be nice to log them in mdl_log too?
- No wait that's probably a nightmare because of what if somebody observes it...
Sam working on this as MDL-58567

It would be nice to display a banner like 'The system is going down in 30 minutes' (similar to unix shutdown)
I think Catalyst made a plugin that does this
Should it be in core? Interface in the current maintenance mode settings, just an option to schedule it there. Should have a choice between ending in 'soft' or 'hard' maintenance mode
Dan says this might already be in core, but seems like it isn't - anyone want to take it?

When only upgrading one plugin and not the whole system - sometimes you need to upgrade a plugin version without any need for downtime - lang string, JS, or CSS. You only need purge caches plus it's nice to indicate that the version changed.
Possible solution - two version numbers, 'soft' and 'hard'. Can work basically the same way but the soft one only does a purge caches
Needs to indicate in the plugin upgrade UI (cli.web) whether the upgrade will require a proper upgrade or not.

One institution runs a read-only copy of the site - with capabilities set so they can't do it