Another one: With topic subscription, flow reply on a topic with a lot of watching user is slow due to inline notification processing,  we have some concern about enabling job queue for all notifications, I submitted a patch to enable this for Flow only:

https://gerrit.wikimedia.org/r/#/c/156598/, it has deployment step in the comment, basically, we need to deploy both Echo and Flow patch, then enable job queue on mediawikiwiki.  If this is a concern for enwiki, then we may need to cherry pick these two patch to enwiki, then enable job queue on enwiki


On Tue, Aug 26, 2014 at 3:57 PM, Benny Situ <bsitu@wikimedia.org> wrote:
As a matter of fact, I don't feel confident enough to deploy wmf18, which is powering mediawiki/metawiki/testwiki now, to all other wikis.  I'd suggest during Thursday auto-deploy train not deploy wmf18 to all other wikis and only deploy master to wmf19 so we can do more test in mediawiki, not sure if this is possible to do.


On Tue, Aug 26, 2014 at 3:42 PM, Benny Situ <bsitu@wikimedia.org> wrote:
Visiting a new topic page in mediawiki/metawiki doesn't mark the notification as read most of the time while testwiki/test2wiki work in all my tests.  This turns out to be a database replication delay, fetching new title from slave in the same request is very likely to fail, testwiki/test2wiki covers the issue with a delay in network request to extension1 db.  I couldn't test this in beta labs which is set up with replication delay, it seemed to have some problems.


On Tue, Aug 26, 2014 at 1:31 PM, Benny Situ <bsitu@wikimedia.org> wrote:
We have introduced an Echo bug during Spring F.  The 'More' link at the bottom of all notification page only shows during initial page load, that means users couldn't view older notifications.  I have submitted a patch to fix this: https://gerrit.wikimedia.org/r/#/c/156445/.  If possible, we should deploy this fix during swat window before it hits enwiki and all other wikis