Change Details

So, often we are informed that there is a patch to review. in most cases, it will be a php patch. however, more and more of MW relies on more and more sophisticated JS code, so more and more patches are JS+css. currently, phabricator users can review the code, but there is no simple way for them to test it, which limits getrrit value to only programmers. i suggest to teach mediawiki code one more address line parameter: just like we have ``` &debug=true ``` which helps debugging JS code by changing the value passed to "src" values in script and style tags, i suggest we teach mediawiki to respect a new ``` &patchtest=012345 ``` parameter, that will look for patch #012345, and if this patch contains any js or css, it will load the appropriate modified files instead of the ones in the distribution. (if no such patch, or the patch has no JS or CSS, this parameter can induce a "patch such and such not found" or "patch such and such has no js or css" comment in the html source). this will allow, in many cases, to ask the original reporter of the bug, and anyone who "confirmed" it with different OSs and browsers, to test the patch, and hopefully comment on the patch with "tested - passed" or "tested, i am still seeing issue such and such". peace

So, often we are informed that there is a patch to review. in most cases, it will be a php patch. however, more and more of MW relies on more and more sophisticated JS code, so more and more patches are JS+css. currently, phabricator users can review the code, but there is no simple way for them to test it, which limits gerrit value to only programmers. i suggest to teach mediawiki code one more address line parameter: just like we have ``` &debug=true ``` which helps debugging JS code by changing the value passed to "src" values in script and style tags, i suggest we teach mediawiki to respect a new ``` &patch-test=012345 ``` parameter, that will look for patch #012345, and if this patch contains any js or css, it will load the appropriate modified files instead of the ones in the distribution. (if no such patch, or the patch has no JS or CSS, this parameter can induce a "patch such and such not found" or "patch such and such has no js or css" comment in the html source). this will allow, in many cases, to ask the original reporter of the bug, and anyone who "confirmed" it with different OSs and browsers, to test the patch, and hopefully comment on the patch with "tested - passed" or "tested, i am still seeing issue such and such". peace

So, often we are informed that there is a patch to review. in most cases, it will be a php patch. however, more and more of MW relies on more and more sophisticated JS code, so more and more patches are JS+css. currently, phabricator users can review the code, but there is no simple way for them to test it, which limits getrrit value to only programmers. i suggest to teach mediawiki code one more address line parameter: just like we have ``` &debug=true ``` which helps debugging JS code by changing the value passed to "src" values in script and style tags, i suggest we teach mediawiki to respect a new ``` &patch-test=012345 ``` parameter, that will look for patch #012345, and if this patch contains any js or css, it will load the appropriate modified files instead of the ones in the distribution. (if no such patch, or the patch has no JS or CSS, this parameter can induce a "patch such and such not found" or "patch such and such has no js or css" comment in the html source). this will allow, in many cases, to ask the original reporter of the bug, and anyone who "confirmed" it with different OSs and browsers, to test the patch, and hopefully comment on the patch with "tested - passed" or "tested, i am still seeing issue such and such". peace