Making it voting is https://gerrit.wikimedia.org/r/586478.

Starter-for-10 is perhaps waiting for the REL1_35 branch and the FR prod migration to REL1_35/fundraising, as that means we don't need to try to back out already-made changes, just block future ones.

+ @Ejegg who has been my historical contact for anything related to CI / DonationInterface.

+ @awight who might have some legacy context from when he was working in the Fundraising team :]

In short: those incompatibilities are for the master branch, but we use REL1_31 version of those extensions!

There is a special job quibble-donationinterface-REL1_31-php70-docker which is triggered for:

• mediawiki/core changes hitting branches matching ^fundraising/REL
• DonationInterface master branch

DonationInterface has a few dependencies that are hardcoded in the job directly:

The job uses branch parameters (--project-branch and --branch) to force branches that will be used regardless of the branch that triggered the build.

The other repositories are forced to use REL1_31.

Stuff we should do:

• maybe move the four dependencies out of the Jenkins job definition to instead have them injected by zuul/parameter_functions.py.
• ensure the job quibble-donationinterface-REL1_31-php70-docker is triggered for all those repositories. So that a change made to cldr REL1_31 branch triggers it.
• 732e3f5b468f92400ca057357a7605aefa725cd6 should be reverted, there is no need for specific jobs. The existing one should be shared by all those repositories/branches instead.

One can think about the quibble-donationinterface-REL1_31-php70-docker job as a gating job between all those repositories. Similar to the wmf-quibble ones for Wikimedia production. Maybe we can prefix those with gate or integrated or anything meaningful.

In the future, we could have all those repositories to have the same branch fundraising/REL1_31 or fundraising/REL1_35 and have them trigger the same job. We could then use the regular Quibble jobs which would nicely simplify the configuration by using a convention (== same branch) instead of configuration (the --project-branch and --branch parameters).

Which mean in an ideal future world:

• one would propose a patch to mediawiki/tools/release to create a fundraising/REL1_35 on all those repositories
• a test fail because CI does not have a shared job between the repositories that will have this branch
• a CI change is made to add Zuul pipelines for that branch on all the repositories
• the change to mediawiki/tools/release is rechecked and pass
• the branches are cut
• folks send patches to those repositories always targeting fundraising/REL1_35
• DonationInterface HEAD is changed from master to fundraising/REL1_35

I note that cldr or ParserFunctions have fundraising/REL1_26 branches. So we definitely used that convention previously and went with -- parameters later on. I haven't dig enough in git history / Phabricator to figure out why.

There is some past history on:

• T199130#4415793
• commit message c58517cd53bbe9adb5f09d06248ff11d6d14a8e4

I guess we should meet with fundraising and define a clear workflow with them? I am strongly in favor of simplifying by using a likely named branch across all those repositories.

Following up on this morning, I wrote a proof of concept to test repos having wmf branches in mediawiki/tools/release have some Zuul configuration in integration/config https://gerrit.wikimedia.org/r/589336

For fundraising, we could use the mediawiki/tools/release make-release script to cut the fundraising/REL* branches on all repositories and use a similar test to ensure that each repository has the proper set of jobs configured in CI.