Release is for any projects releases, using Release-Engineering-Team instead as there is no project for the WM release tools.

Found a better one.

Sounds like we should make CentralNotice use the ordinary setup instead of changing make-wmf-branch.

Also, note that we did recently lose /srv/mediawiki-staging. I wonder what happened to CentralNotice while it was being rebuilt.

Sounds like we should make CentralNotice use the ordinary setup instead of changing make-wmf-branch.

That would be preferable, if it doesn't work, at least changes should be submitted in gerrit to its special snow flake branch and then the core wmf branch submodule updated. However because of the deviation from the usual workflow these special branches have currently many problems we didn't yet solve.

I think the title of this task is misleading.

Thank you both for taking a look at this! It's very possible that I don't understand how release branching works at the WMF, and I'd be happy to make our workflow more regular if that would satisfy our requirements.

The reason we're using a named deployment branch in CentralNotice is so that we can continue using the master branch for development and code review, and our criteria to merge is simply "do we want to eventually deploy this code". However, very often we need to deploy in phases, or even postpone deployments during a high-volume fundraising campaign. For these reasons, we don't want to deploy whatever is on the master branch with the weekly train.

Is there an alternative we should be looking into?

Is there a requirement to always deploy on all wmf branches at the same time (or all wikis need to be the same CentralNotice version even when the core wmf deployment branch is different)?
Is there a requirement for the opposite, that you may need to have different CentralNotice version on different wmf deployment branches?

This....should be working with branch.py as desired?

I don't know why it says I removed a subscriber @awight