On 4 October 2011 22:42, Yaron Koren yaron@wikiworks.com wrote:
Hi,
So let me propose a technical solution that is hopefully fully feasible: instead of separating out access by core MediaWiki vs. extensions, separate it out as: 1) core MediaWiki, 2) extensions used on public Wikimedia wikis, and 3) all other extensions. Or the separation could even be just MediaWiki core + WMF-used extensions vs. other extensions - two sets of code, separated by whether they're used on Wikipedia and the like.
This would be great, apart from one thing: new extensions are installed on WMF wikis on a fairly regular basis. Moving extensions between SVN repos, or even between separate branches, would be extremely disruptive right across the board, so this disctinction would at best be accurate only at the time the repository was reconfigured. At worst, we'd end up forking extensions once they were installed on the cluster, with all new development being made to the WMF version while users of the old version are left to rot, blisfully unaware that the code they are using is no longer getting any TLC.
This ties in to something else I've thought about for a while: that maybe the CodeReview protocol should similarly be bifurcated, so that non-WMF extensions like, say, SocialProfile, don't get the same level of scrutiny as extensions like ParserFunctions. As an extension developer, I'm grateful for all the helpful reviews that my commits get - but if all that reviewing work is coming at the expense of the reviewing of code that's used on WMF sites, then it seems like a waste of resources.
This already happens, although more by default than through design. Whole swathes of commits to extensions and branches are already automatically marked "deferred" in CR; usually that means that the amount of code review it will receive is nil. Our problems with code review are not due to the distraction of random extensions!
--HM