A fundamental principle of medicine is "do no harm." It has a long history and
you can find it in the Hippocratic oath with a slightly different wording.
This is also an important principle of software development. If you add a new feature or
fix a bug, make sure the resulting code isn't worse off than before. Do no harm is the
basic motivation behind regression testing.
I have been thinking about Brion's suggestion of fixing the bug in
WebRequest::extractTitle(). It is a reasonable point. Don't just whine about a
problem. Fix it. He even provided the best strategy for accomplishing this. Make
"sure $wgScriptPath gets properly escaped when initialized." I am sure doing
this would not require a significant amount of coding. But, how would changing the way
$wgScriptPath is formatted affect the rest of the code base?
I decided to do a multi-file search for $wgScriptPath in phase3 and extensions [r53650].
There are 439 references to it in phase3 and extensions combined. In phase3 alone, there
are 47 references. Roughly 1/3 of these are in global declarations, so phase3 has about 30
"active" references and in phase3 and extensions combined there are roughly 300.
[By "active" I mean references in which the value of $wgScriptPath affects the
code's logic.]
So, if I were to change the formatting of $wgScriptPath, there potentially are 30 places
in the main code and 300 places in extensions where problems might occur. To ensure the
change does no harm, I would have to observe the effect of the change on at least 30 and
up to 330 places in the distribution. This is pretty onerous requirement. My guess is very
few developers would take the time to do it.
On the other hand, if there were regression tests for the main code and for the most
important extensions, I could make the change, run the regression tests and see if any
break. If some do, I could focus my attention on those problems. I would not have to find
every place the global is referenced and see if the change adversely affects the logic.