(NB: This proposal is basically how FB does their deploy cadence, other than how the gradual rollout happens. Essentially weekly starting on Monday.)

If we did this we should automate the cutting (and testing) of the new branch like Sunday night.

Why MTuW instead of TuWTh? (deploying on monday means you're rushed to fix any bugs that might have been discovered over the weekend)

In T97553#1246327, @demon wrote:

If we did this we should automate the cutting (and testing) of the new branch like Sunday night.

+1

In T97553#1246343, @Legoktm wrote:

Why MTuW instead of TuWTh? (deploying on monday means you're rushed to fix any bugs that might have been discovered over the weekend)

Not a bad point.

We really need to automate the branching stuff anyway - it's really time consuming and error prone. the way it is now wastes not just my time but @aude's and anyone else who works on extensions regularly.

There is no sane reason to cut new deployment branches manually every week. In many cases nothing even changes between branches.

I'd also suggest TuWTh so that the preponderance of holiday Mondays doesn't massively disrupt schedules. (As well as @demon's, @mmodell's and @Legoktm's points.)

I'm confused at how the best case would be 3 days but worst case 10 days?

In T97553#1246722, @mmodell wrote:

I'm confused at how the best case would be 3 days but worst case 10 days?

If you merge into master right after the new branch which happens on say Tuesday May 5th. You're commit will go out in the next branch which is cut on Tuesday May 12th, which goes to English Wikipedia on Thu May 14th. 9 or 10 days depending on how you count Tuesday the 5th.

If you merge right before the branch cut on Tuesday May 5th then it'll go to English Wikipedia on Thur May 7th. 2 or 3 days depending on how you count.

@mmodell: The person this most affects day-to-day is you. I'm fine with making the change (with giving people ~2 weeks of warning) at any point now. What are your thoughts on that?

@greg: I'm ok with it. I'll have to adjust my scripts a bit. Will we use the same time slot for the Thursday deployment window as we do on Tuesday and Wednesday?

@mmodell yeah, 11am on all those days. Shall we decree to start doing this the week of .... /me looks at a calendar....June 8th?

ok

So cut new branch and deploy to group 0 on tuseday, deploy to group 1 on wednesday, deploy to everything else on thursday, rinse and repeat?

I updated the description to be a little more clear. I'll add it to my calendar for the 8th.

I have added T437: Track state of browser tests before new wmfXX branch cut as a blocker since we want to run smoke browser tests at some point.

I have troubles understanding the word "simplify". What's simpler? The difference from quickest to slowest, which is currently 100 %, will become 233 %. Therefore people will need to check their calendars and calculate time intervals much more carefully.

In T97553#1320304, @hashar wrote:

I have added T437: Track state of browser tests before new wmfXX branch cut as a blocker since we want to run smoke browser tests at some point.

This isn't a blocker for this change, but is still something we should do.

In the announcement email, @greg wrote:

Transition

Transitions from one cadence to another are hard. Here's how we'll be
doing this transition:

Week of June 1st (next week):

• We'll complete the wmf8 rollout on June 3rd
• However, we won't be cutting wmf9 on June 3rd

Week of June 8th (in two weeks):

• We'll begin the new cadence with wmf9 on Tuesday June 9th

So I won't be branching wmf9 today.

Change 215679 had a related patch set uploaded (by 20after4):
All wikis to 1.26wmf8, no new branch today per T97553

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

Change 215679 merged by jenkins-bot:
All wikis to 1.26wmf8, no new branch today per T97553

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