<quote name="Tyler Romeo" date="2014-03-07" time="16:54:27 -0500"> > On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen > <mflasc...@wikimedia.org>wrote: > > > 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 -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
