summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <lwirzenius@wikimedia.org>2019-05-02 20:09:11 +0300
committerLars Wirzenius <lwirzenius@wikimedia.org>2019-05-02 20:09:11 +0300
commit90edeaa1871ff2ab806ea9e93d7a6eef570a2146 (patch)
treec90b0e8aa2d0019285f3dfab285843df1e1a1433
parent45d9a6ffa2fa4bf7a1f98a6f3f5a758402c4b65d (diff)
downloadwmf-ci-arch-90edeaa1871ff2ab806ea9e93d7a6eef570a2146.tar.gz
Change: clarify interdep changes
-rw-r--r--ci-arch.mdwn15
1 files changed, 14 insertions, 1 deletions
diff --git a/ci-arch.mdwn b/ci-arch.mdwn
index 8e1ace6..9ce72dc 100644
--- a/ci-arch.mdwn
+++ b/ci-arch.mdwn
@@ -323,11 +323,24 @@ we plan CI to implement them.
* this is the simplest possible use case for CI
-## interdependent changes
+## Interdependent changes
* changes to two or more components that must all be applied at once
or not at all, e.g., to mediawiki core and an extension
+* in this scenario the change to MediaWiki core and the change to an
+ extension may depend on each other, so that if either is deployed
+ without the other, the system as a whole breaks; thus, either both
+ changes get deployed, or neither
+
+* Lars's opinion: this seems like a bad way of managing development.
+ It seems better to be careful with such changes so that they can be
+ disabled behind a feature flag in the configuration, or by
+ autodetection of the other component, so that if only one component
+ has been changed, it can stillbe deployed. Only when both components
+ have been changed in production is the feature flag enabled, and the
+ new feature works.
+
## Security embargoed change
* change can't be public until it's deployed or manually made public