What should happen to tasks when they get added here? Should they be closed, or should they be kept open (or 'stalled'?) until after deployment, then closed after testing?

I'm closing them, since they are resolved upstream and we are only waiting for their deployment here. There is nothing else to do about them, so I'd rather remove them from lists etc.

Is this upgrade in fact blocked by T85123: Create a continuous integration plan for Wikimedia Phabricator patches and the fact that @mmodell and @Christopher's large patches on the Security and Sprint extensions need to be in sync? @modell also mentioned somewhere that upstream has done giant steps in the past weeks, making this upgrade specially complex.

In T78243#958938, @Qgil wrote:

Is this upgrade in fact blocked by T85123: Create a continuous integration plan for Wikimedia Phabricator patches and the fact that @mmodell and @Christopher's large patches on the Security and Sprint extensions need to be in sync? @modell also mentioned somewhere that upstream has done giant steps in the past weeks, making this upgrade specially complex.

Most relevant cross post: https://phabricator.wikimedia.org/T518#957604

Essentially, we spent time deploying the "new fangled security extension" but it didn't go great. We ran into some purely deployment problems, which we solved. But there was an issue with some existing behavior (where you can transform an existing issue that has already been created by selecting the security bug option in the drop down) and the behavior that was not doing the expected has been noted as super important before by @csteipp. So in the end we fell back to the older extension version.

To top it off upstream has made some underlying changes to teh CC infrastructure (really making it more consistent on their side) but that means @mmodell has to step back and incorporate those into the "any cc'd user can access the ticket" logic he wrote.

On top of that, the Sprint app needs to coordinated with the version of Phab we are running.

At the end of Monday (5th) I asked Mukunda if he could sync with christopher on a version of phab so they have common expectation and Mukunda is going to work out the kinks in the extension.

We could in theory upgrade while using the older extensions, assuming it works but that would entail coordination with @Christopher at least.

Upstream had bigger changes so for our next upgrade / pull we'll have to take Phab down for a bit longer (max 2h, to be on the safe side?).

I think the security extension is ready: https://gerrit.wikimedia.org/r/#/c/183457/

I've tagged the relevant commits in the libphutil and phabricator repos as release/2015-01-08/1
I also made sure the changes are on a branch named 'production'

Sprint 0.6.2.7 needs to be part of this phabricator upgrade. @chasemp, please note that keeping the old Sprint extension with the new phabricator will not work. I just checked out the "production" branch based on c0e15f2c6587d68bdc894d365fe0a8ddc04bde6f and tested it with Sprint on phab08.wmflabs,org and there do not seem to be any new breaking changes.

As requested in T85123, the Sprint extension has been tagged with the same tag: release/2015-01-08/1 and has a branch called production.

@Christopher: Awesome, thanks for that.

Change 184802 had a related patch set uploaded (by Rush):
phab update (and peripherals) for T78243

https://gerrit.wikimedia.org/r/184802

Patch-For-Review

I closed the maint window, I think things are ok (did brief resanity testing that the securityevent listener is...listening). Search has to reindex which will take awhile. Currently at 19%

fwiw indexable docs:

Indexing 17 object of type CONP.
Indexing 86144 object of type TASK.
Indexing 5 object of type CDTL.
Indexing 999 object of type PROJ.
Indexing 371602 object of type CMIT.
Indexing 1474 object of type USER.
Indexing 34 object of type MOCK.