<quote name="Tyler Romeo" date="2014-03-07" time="16:54:27 -0500">
On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
Yes, it does. Unless the entire branch has a serious problem (500s or major caching problems, etc.), we don't generally switch the entire branch back.
That means the only option is fix or revert a commit. The general rule is to do changes in master before cherry-picking to the branch.
What you're saying is that the software development process for MediaWiki is so tightly coupled with the operations deployment process, that development has to be held up because of problems in operations. That's a problem.
Or a benefit, giving third-party users confidence that the core they use has a quick feedback loop with real users and is thoroughly tested.
It's all about perspective.
From these conversations, your perspective seems to be (and please
correct me if I'm wrong) that what WMF does with deployed code should have no bearing on MediaWiki core/master. And that all of our massive testing infrastructure equally shouldn't touch core/master.
Our "massive testing infrastructure" includes the Beta Cluster, Jenkins, SauceLabs, and the group0 wikis (test.wikipedia, mw.org etc). And, let's be realistic, the Wikimedia community as a whole. Code is never really tested until real users interact with it.
I probably mischaracterized your perspective, but I kinda wanted to make a point that this is all done with quality in mind, not the other way around.
Do you have a recommendation on how we would 'decouple' this while also keeping the same short feedback loop and testing rigor that we do have (and intend to increase, both in rigor and in speed of feedback)?
Thanks,
Greg