Regarding option 1.: This option doesn't sound feasible to me. There has been predecessors to my knowledge where such setup is a) slowing down development for everyone else and b) has also negatively impacted velocity widely.

Regarding option 2 and "is not possible at the moment": The dependency might be able to have introduced, for example https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/refs/heads/master/zuul/dependencies.yaml#1623 In my understanding it could check a new Vector patch against RL master and vice versa.

For option 2, dependencies.yaml only defines which other extensions (e.g. BetaFeatures) need to be cloned when tests are run for a particular extension (e.g. ReadingLists). This does not cause tests to run for these other extensions when there is a change in ReadingLists.

Addressing https://phabricator.wikimedia.org/T404403 would help make this possible and it would be ideal if we can have this capability.

I am looking further at feasibility of option 2 and think it is possible:

https://phabricator.wikimedia.org/T404403#11789407

Both option 2 and option 3 would require to check with the release engineering team to make sure they support the approach. I would like to try option 2.

I put together a proof of concept for implementing option 2, as described in https://phabricator.wikimedia.org/T404403#11793824

I would like that approach if possible

I think we want to do https://phabricator.wikimedia.org/T404403 instead. Either approach requires support from release engineering or whichever team maintains the CI infrastructure.

There is a proof of concept patch for T404403: https://gerrit.wikimedia.org/r/c/integration/config/+/1268556