<quote name="Pine W" date="2016-08-11" time="22:25:15 -0700">
== Conclusions ==
- Our code review practices are lax, including merging hairy patches
without testing and self-merges.
Is there a way to improve how code review is done such that appropriate testing would have happened in advance? I'm not referring to this specific case so much as the more general case of making sure that appropriate tests are written and done. Is there a "process owner" for code review who might take a look at this situation and see what can be learned from it for the general code review process?
We haven't previously officially appointed a process owner for code review, but the Release Engineering Team and/or ArchCom are the closest things. The code review infrastructure is owned by RelEng, clearly, at least.
To answer the other question: Yes, we (RelEng, at least) are looking into improvement to the code-review process. There are a few related things happening:
* I working to get more explicit statements on what WMF teams consider the set of components for which they own the code review backlog and/or response to issues in production. See a first pass at: https://phabricator.wikimedia.org/T115854
* There has been continued effort by Developer Relations to improve the code review backlog 'issue'. See past work and potential future work as the subtasks of https://phabricator.wikimedia.org/T78768
There's more, but these are the highlights for now.
To more directly answer the question: Yes, we (RelEng) are looking into the situation to see what we can learn from it. I don't see one specific actionable coming out of this specific incident, but instead a group of related endeavors (some small, some large) where some are already in progress and others are still in the planning/formative stage as the way forward.
Best,
Greg