Change Details

We should disable the dependant gate because it is too disruptive: * The Zuul queue concept not working well due to practically all projects being in the same queue (so any change in any branch of any project is blocked on all other changes anywhere else). * It exposing code paths in Zuul that cause dead locks (T93812). * Limitations in its implementation (it's not all that smart, and doesn't prevent incompatible changes, only if they happen to be merged within the same ~ 10 minute window). Here's a brief example of what a dependent pipeline does: > Imagine two changes, A and B, sitting in code review. One in an upstream-like project, and one downstream. The changes are incompatible. For example, commit A in MediaWiki core removes the deprecated function wfExample(), and commit B in a MediaWiki extension adds new code introducing a call to that same function. > > Scenario 1 (Perfect): >Commit A is merged first. Later, a user tries to merge commit B. In the final test ("gate"), commit B will fail (as it should). This is because we locally merge the commit into latest master, and use latest master of upstream. The test fails, commit B merge gets rejected and will need amending. > > Scenario 2 (OK): > Commit B is merged first. Later, commit A is merged. The extension is now incompatible with MediaWiki master. Users will not discover that until the next commit. This is normal in software development. In next commit the maintainers find out and fix it. This like like the amend in Scenario 1, but with separate commits. > > Scenario 3 (Perfect): > Users try to merge commit A and B around the same time. Without a Dependant Pipeline, this would follow Scenario 1 or 2 (in paralel). But a Dependant Pipeline can help catch the incompatibility earlier (in this commit, instead of the next). Zuul will speculate that Commit A passes tests and gets merged. When Zuul sends commit B to Jenkins, commit A is still being tested. Yet, it will test commit B with MediaWiki master including commit A. Thus, commit B will fail (as it should). So it can only help in one of three scenarios. Without a dependant gate pipeline, scenario 3 will be like scenario 2. Which is quite normal and probably what most people expect would happen. A dependant gate pipeline is a really cool concept but not well known. Before we consider re-enabling it, we should get the following sorted out: * Deadlock caused when changes are merged manually fixed (T93812). * Projects should not all share the same queue (e.g. "mediawiki"). We have to find a way to drastically reduce our queue sizes. I'm thinking maybe we disable automatic queueing completely and do it manually. Remember that this is an optimisation (Scenario 3), it is not critical. So whenever in doubt, it is better to not depend (opt-in, not opt-out). * ...anything else?

We should disable the dependant gate because it is too disruptive: * The Zuul queue concept not working well due to practically all projects being in the same queue (so any change in any branch of any project is blocked on all other changes anywhere else). * It exposing code paths in Zuul that cause dead locks (T93812). * Limitations in its implementation (it's not all that smart, and doesn't prevent incompatible changes, only if they happen to be merged within the same ~ 10 minute window). Here's a brief example of what a dependent pipeline does: > Imagine two changes, A and B, sitting in code review. One in an upstream-like project, and one downstream. The changes are incompatible. For example, commit A in MediaWiki core removes the deprecated function wfExample(), and commit B in a MediaWiki extension adds new code introducing a call to that same function. > > Scenario 1 (Perfect): >Commit A is merged first. Later, a user tries to merge commit B. In the final test ("gate"), commit B will fail (as it should). This is because we locally merge the commit into latest master, and use latest master of upstream. The test fails, commit B merge gets rejected and will need amending. > > Scenario 2 (OK): > Commit B is merged first. Later, commit A is merged. The extension is now incompatible with MediaWiki master. Users will not discover that until the next commit. This is normal in software development. In next commit the maintainers find out and fix it. This like like the amend in Scenario 1, but with separate commits. > > Scenario 3 (Perfect): > Users try to merge commit A and B around the same time. Without a Dependant Pipeline, this would follow Scenario 1 or 2 (in paralel). But a Dependant Pipeline can help catch the incompatibility earlier (in this commit, instead of the next). Zuul will speculate that Commit A passes tests and gets merged. When Zuul sends commit B to Jenkins, commit A is still being tested. Yet, it will test commit B with MediaWiki master including commit A. Thus, commit B will fail (as it should). So it can only help in one of three scenarios. Without a dependant gate pipeline, scenario 3 will be like scenario 2. Which is quite normal and probably what most people expect would happen. A dependant gate pipeline is a really cool concept but not well known. Before we consider re-enabling it, we should get the following sorted out: * Deadlock caused when changes are merged manually fixed (T93812). * Projects should not all share the same queue (e.g. "mediawiki"). We have to find a way to drastically reduce our queue sizes. I'm thinking maybe we disable automatic queueing completely and do it manually. Remember that this is an optimisation (Scenario 3), it is not critical. So whenever in doubt, it is better to not depend (opt-in, not opt-out). * ...anything else? ----- Follows-up T50419.

We should disable the dependant gate because it is too disruptive: * The Zuul queue concept not working well due to practically all projects being in the same queue (so any change in any branch of any project is blocked on all other changes anywhere else). * It exposing code paths in Zuul that cause dead locks (T93812). * Limitations in its implementation (it's not all that smart, and doesn't prevent incompatible changes, only if they happen to be merged within the same ~ 10 minute window). Here's a brief example of what a dependent pipeline does: > Imagine two changes, A and B, sitting in code review. One in an upstream-like project, and one downstream. The changes are incompatible. For example, commit A in MediaWiki core removes the deprecated function wfExample(), and commit B in a MediaWiki extension adds new code introducing a call to that same function. > > Scenario 1 (Perfect): >Commit A is merged first. Later, a user tries to merge commit B. In the final test ("gate"), commit B will fail (as it should). This is because we locally merge the commit into latest master, and use latest master of upstream. The test fails, commit B merge gets rejected and will need amending. > > Scenario 2 (OK): > Commit B is merged first. Later, commit A is merged. The extension is now incompatible with MediaWiki master. Users will not discover that until the next commit. This is normal in software development. In next commit the maintainers find out and fix it. This like like the amend in Scenario 1, but with separate commits. > > Scenario 3 (Perfect): > Users try to merge commit A and B around the same time. Without a Dependant Pipeline, this would follow Scenario 1 or 2 (in paralel). But a Dependant Pipeline can help catch the incompatibility earlier (in this commit, instead of the next). Zuul will speculate that Commit A passes tests and gets merged. When Zuul sends commit B to Jenkins, commit A is still being tested. Yet, it will test commit B with MediaWiki master including commit A. Thus, commit B will fail (as it should). So it can only help in one of three scenarios. Without a dependant gate pipeline, scenario 3 will be like scenario 2. Which is quite normal and probably what most people expect would happen. A dependant gate pipeline is a really cool concept but not well known. Before we consider re-enabling it, we should get the following sorted out: * Deadlock caused when changes are merged manually fixed (T93812). * Projects should not all share the same queue (e.g. "mediawiki"). We have to find a way to drastically reduce our queue sizes. I'm thinking maybe we disable automatic queueing completely and do it manually. Remember that this is an optimisation (Scenario 3), it is not critical. So whenever in doubt, it is better to not depend (opt-in, not opt-out). * ...anything else? ----- Follows-up T50419.