MediaWiki / Phabricator / Maintenance
Event: E19: Phabricator Deployment Wednesday, June 24th Midnight UTC
Previous deployment: T101929
MediaWiki / Phabricator / Maintenance
Event: E19: Phabricator Deployment Wednesday, June 24th Midnight UTC
Previous deployment: T101929
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | mmodell | T102276 Phabricator: new users get "Login cookie was set correctly, but your login session is not valid." | |||
Resolved | mmodell | T102180 Email preferences doesn't contain an entry for Project Subscriber updates | |||
Resolved | Glaisher | T88899 Allow sorting by oldest and newest in Date Update/Created in search queries | |||
Resolved | mmodell | T102095 Next Phabricator upgrade: 2015-06-24 |
@Christopher: Upstream phabricator is now publishing updates on twitter when they upgrade their own cluster, so perhaps we should endeavor to follow the same stable version that they push:
@mmodell That is a good idea.
Also, please post (publicly) the current diffusion commit of Wikimedia Phabricator for external reference. It is difficult to reconcile the git commit hashes in gitblit with the upstream revisions.
Upstream is running https://secure.phabricator.com/rPb4de79741cebb6a8c13d4e3c4ae0f7ca7b78e8db from 6 June.
Last week, you pulled HEAD (10 June) right? https://secure.phabricator.com/rPc075f7f63f714a1dc180ec4d56b43ed81c73caa7
So, does not this mean that Wikimedia production is currently ahead of the upstream cluster?
The new UI is in a separate branch and not in master, see https://secure.phabricator.com/T8549
I couldn't log in to labs to test the latest update so today's deployment window didn't get used. I guess this has to be rescheduled.
@Christopher: The upstream project just recently started running a 'stable' release - they even have a stable branch of libphutil, arcanist and phabricator. I have begun syncing up with the stable branch instead of master, and we are now nearly, but not quite, up to date with upstream/stable.
Also note: Now that we have merges in our fork, our SHAs will no longer match upstream's, even when we are running nearly-identical code (We have merged a few tiny WMF-specific changes at this point)
@mmodell Since most of Wikimedia's custom code has been made into an extension, could we get the small amount of code that is being merged in also into an extension? This would make deployments simpler and easier to track. Perhaps just a misc extension if code is too small to be made into a full extension.
@Negative24: unfortunately, no. Some changes don't work as extensions as extensions do not overlay or override built-in/core functionality. Extensions are only viable for situations where there is an explicit integration point built in to the upstream application.
Hacks to override things that upstream explicitly doesn't support modifying, can't be done with extensions.