@greg-g we have a feature branch that we want to merge into master, but we want to deploy it to one project first.
What is the best way to do this (please ping whoever in your team makes most sense to talk through this with)? I see two options (but please suggest more):

• Point the project to the feature branch of MobileFrontend temporarily (is this easy? possible?).
• Organise two (maybe more) swat deploys swat to master during the relevant roll out to the train deployment window to SWAT a squashed patch of the feature branch.

Lucky this pinged me on IRC with "greg-g" there, otherwise I wouldn't have seen it :)

Why not a feature flag and associated mw-config setting?

Hey @greg sorry about that! :) It's a redesign and historically we've found these difficult to maintain (we always have to think about the 2 designs until the new one is done) we wanted to free ourselves from this burden. Thus, the old design does not exist in the new branch and is not feature flagged. Adding a feature flag and making it possible to switch between the two designs will add considerable work (probably 2 weeks) which we'd rather avoid. We have been asked by discovery team to check how our UI changes impact searches (to see if they are consistent with our prototyping results) hence the unusual roll out plan.

With this in mind what would you recommend?

Feature flagging the branch now is going to be quite a pain.

Another thing we can do is merge after train rollout and swat to the specific project, that'd give us some days to test on the wiki and revert the change if there are problems.

How would you "swat to a specific project" without a feature flag/config that you can set in mw-config?

That's what we're trying to work out. We can package the changes up into a single patch that we can then SWAT to the master branch of the project we want it to be on... but the perfect situation would be if we could temporarily point say French Wikipedia to a branch other than master.

There are no master branches per project. There's group0, group1, and group2. To do things per project you need a config variable.

Given the most active group0 wiki is mediawiki we'd probably want to go with group1 wiki, but preferably only switch the branch for group 1 wikipedias (e.g. Hebrew and Catalan Wikipedia).

Is that possible?
When you say "There are no master branches per project." do you mean MobileFrontend cannot be switched to something other than master or a specific production site cannot be switched?
i.e. could we set group1-wikipedia to the branding branch for a 2 week period?

@ovasileva and @bmansurov sounds like we might need to schedule some time with @greg 's team to work out a roll out strategy. Can one of you set something up based on the schedule for deploying this UI change?

In T156794#2997659, @Jdlrobson wrote:

Given the most active group0 wiki is mediawiki we'd probably want to go with group1 wiki, but preferably only switch the branch for group 1 wikipedias (e.g. Hebrew and Catalan Wikipedia).

Is that possible?

No, it isn't.

When you say "There are no master branches per project." do you mean MobileFrontend cannot be switched to something other than master or a specific production site cannot be switched?
i.e. could we set group1-wikipedia to the branding branch for a 2 week period?

No, we can't do that for an individual submodule. We'd have to great a whole special branch just for the wikis you're targeting (for core + your extension). The overhead would be obnoxious for deployment and this is totally uncharted territory.

The standard practice here is a feature flag.

Thanks for the input @demon @greg

Change 336353 had a related patch set uploaded (by Jdlrobson):
WIP: Allow feature flagging of new header

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

So actually after a bit of playing around with this, I've found a compromise that's now @Nirzar approved after I spoke to him in the office.

@ovasileva: basically we'd roll out all the new changes except the branding in the header and the search icon which you are worried about (the most noticeable being notifications icon). This will allow us to roll out the search icon change and test on Catalan wiki. During this period there would be no indication if you are in the stable or beta channel.

For all users outside the wiki we want to test on this is what it would look like while we run our test:
http://reading-web-staging.wmflabs.org

What do you think?
PS. We should probably think about QA for both the interim state (http://reading-web-staging.wmflabs.org/wiki/1) right now so we can merge that into master.

@Jdlrobson - so basically we would pull the search icon and feature flag it separately? I think that works!

Change 336459 had a related patch set uploaded (by Jdlrobson):
Allow feature flagging of new header

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

• Create a task to remind us to conclude the test in 2 weeks time and how to continue rolling out - we might not need this if there's no changes to search

^ I'm not sure why this was moved into Blocked Externally in T156794#3028070. This code'll start riding the train today with the new search bar disabled (by default).

The train rolling doesn't block us from SWAT deploying a config change to enable the new search bar for cawiki and itwiki but it does block @ovasileva signing it off.

Change 339370 had a related patch set uploaded (by Phuedx):
Enable new Minerva header on cawiki and itwiki

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

If someone familiar with MobileFrontend's feature flagging system could +1 rOMWC6abfbe30515a: Enable v2 of Minerva's header on cawiki and itwiki, that'd be grand /cc @bmansurov @Jdlrobson

Change 339370 merged by jenkins-bot:
Enable v2 of Minerva's header on cawiki and itwiki

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

Mentioned in SAL (#wikimedia-operations) [2017-02-23T14:26:36Z] <addshore@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT T156794 [[gerrit:339370|Enable v2 of Minerva's header on cawiki and itwiki]] (duration: 00m 42s)

@ovasileva, @Nirzar: See https://ca.m.wikipedia.org/wiki/Special:Random. -wmf.13 will be deployed to the group2 wikis at 8 PM UTC today and you'll be able to see it on itwiki too.

No bugs, but notifications look VERY misaligned in Chrome
Chrome (logged out)

The logo is actually aligned properly but due to the nature of the descender on Q in the logo it looks misaligned. we will need to add a specific rule for catalan wikipedia to move it down 1px. but the default padding is correct.

The notification bubble needs to be fixed!

Update: Pau helped an admin to add commons.css rule on catalan wikipedia to fix the alignment as this is exclusive to ca wiki.

sending this back to needs more work then

over to you @Nicholas.tsg (cc @ABorbaWMF) - testing criteria in the description

I tried on a bunch of combinations. Some browser appear to have larger alignment problems than others. Screenshots below:

Screenshots	Android Device OS - Browser Version	iOS Device OS - Browser Version
	Nexus 6P Android 7 - Firefox 50	iPhone 6 iOS 8.1 - Safari 8.0
	Galaxy Note 3 Android 4 - Chrome 44	iPhone 6+ iOS 9.0 - Chrome 47
	Nexus 9 Tablet Android 6 - Chrome 55	iPad Air 2 iOS 9.0 - Safari 9.0
	Galaxy S6 Android 5 - Android Browser 5.0	iPhone 5s iOS 7.0 - Safari 7.0
	Galaxy S6 Android 5 - Chrome 52	iPhone 6s+ iOS 9.0 - Chrome 47
	Nexus 6P Android 7 - Maxthon 4.5	iPad Mini Retina iOS 7.0 - Dolphin 7.5

@Nicholas.tsg - I think we are good on test this one for now.

Moving back to needs more work.