Last modified: 2013-07-05 15:02:52 UTC
It would be neat if extensions could decide on what exactly is being deployed. Currently, it looks like all extensions' master branches are checked out periodically. I could pull in whatever code I want, but it'll automatically be overwritten not too much later. This makes it "hard" to thoroughly test new features: everything is expected to be code-reviewed and merged already, before it can even be tested on labs. Ideally, code should be testable _before_ it's merged into the codebase: * It would allow non-tech people to test stuff before it's merged already - otherwise they can only provide feedback after the code has been merged already * It seems rather "unsafe" in the first place to merge stuff that has not yet been tested in a production-like environment Possible solutions: for every extension, check if there is a remote "beta" branch. If there is, check that branch out, otherwise check out master. Master would be the Gerrit-gated trunk; beta could be an ungated push-whatever-whenever-you-want branch.
Beta has been used to test out git-deploy over the last two weeks. The wiki are currently working off the wmf branches (1.21wmf7 for most wiki). Ideally we would want to run from a self updating master again. The automatic updater I wrote a while back need to be updated to support git-deploy, I guess it could detect whether an extension as a beta branch and use it instead of master.
Doing this for AFTv5 would require these steps: Track the "prototype" branch instead of the "master" branch: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki%2Fextensions%2FArticleFeedbackv5.git;a=shortlog;h=refs%2Fheads%2Fprototype Database updates from these commits (one time only): https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/ArticleFeedbackv5.git;a=commit;h=824fa53f02d155ee7858016c689a131b8b697e61 https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/ArticleFeedbackv5.git;a=commit;h=fd9fbd418b1eaf41c69216d7c6b987823f5a779e We also want AbuseFilter configured properly. (AbuseFilter looks to be in place in beta labs enwiki, tracking master branch. No prototype branch exists for AbuseFilter. ) Raising the priority of this issue. Could we deploy this from a Jenkins build instead of from the updater?
Beta might not be able to support this approach uickly. Would it be possible to merge code to master but have new features hidden in production by a "Feature Toggle" like Martin Fowler describes? http://martinfowler.com/bliki/FeatureToggle.html
A feature toggle is the typical case of a configuration setting disabled by default. Of course that could be used, although I'm not sure that it's the best path.
We have been using feature toggling for years and years and that prove being very successful and easy to handle. That does not discard this bug report though. Anyway, beta is setup to load extensions using the mediawiki/extensions.git repository. We add extensions manually as submodules there, the .gitmodules as a branch parameter which might be used for that. So potentially we could create a 'beta' branch in mediawiki/extensions.git and point the submodule branch to 'prototype'.
From a discussion I had within the team in charge of deploying changes on the Wikimedia cluster, we want to stick to feature toggling since that is how we handle deployment in production.
