Hi Joachim,
thank you for your message. I agree that it'd be brilliant if third-party
users wouldn't have to branch MediaWiki for their code! Hiding some things
behind a configuration variable, like how Markus suggested, is certainly
doable, to an extent. However, there will be things that need to be
rethought and maybe even completely rewritten; patches like
http://trac.wikia-code.com/changeset/11900/wikia/trunk/includes/api come to
mind. Likewise, both Wikia and wikiHow have some custom methods and member
variables in some core files, such as includes/User.php; some can be moved
to a custom class and/or done via hooks, but there are some things that I'm
not too sure of, such as wikiHow's getBotIDs() method in includes/User.php,
for example.
I actually sent this message to wikitech-l and CC'd various third-party
developers on it; I don't know why your message isn't showing up in the
wikitech-l archives (
http://lists.wikimedia.org/pipermail/wikitech-l/2011-August/thread.html),
though.
Like K. Peachey mentioned earlier, using SVN's "external" property might be
a good way of including libraries that we don't want to host on
svn.wikimedia.org for one reason or another.
I'd like to know more about frameworks used by third parties and why you use
them. If I recall correctly, wikiHow uses Prototype for some of their
JavaScript code, but they're moving towards jQuery. Wikia has various
different frameworks (
http://trac.wikia-code.com/browser/wikia/trunk/lib) on
their SVN, such as phpFlickr, PHPUnit, Stomp and more.
One interesting point to consider is the edge case of having to edit library
code for some reason. For example, you might need to fix a PHP notice (like
what was done in
http://trac.wikia-code.com/changeset?new=40808@wikia%2Ftrunk%2Flib%2FHTTP&a…)
or even a fatal or something like that. What'd be the best solution in such
case? I think that submitting a patch to the upstream developers of the
library would be the best approach, obviously, but it might be that some
libraries aren't even maintained anymore or the maintainers do not have very
much time...maybe then we should note somewhere that you need to patch the
code.
Let's say that we have an extension called FooBar in
svn.wikimedia.org/mediawiki/trunk/extensions/FooBar. It has an external
dependency on a library called Baz, which is hosted on Google Code. However,
line 15 of Baz's BazClass.php contains code that throws a notice on modern
PHP versions. In this case, I'd keep the Baz library as the svn:external of
the FooBar extension but I'd add a README to the extension directory, to
explain what needs patching in the external library and why and how to apply
the patch.
On Fri, Aug 26, 2011 at 7:08 PM, Joachim Bode <joachim.bode(a)twoonix.com>wrote;wrote:
Hi Jack, hi all,
I think it is indeed a good idea to provide a possibility for 3rd party
devs to store branches at /mediawiki/branches/. To me the attempt of
creating a way to add additional hooks *without* having to branch, that is
tied to this question, is even more important. I like Markus' idea of a
$wgExecuteExpensiveHooks Setting.
How about CC-ing the wikitech-l list for this?
We use GIT internally, but I don't Know about an option that allows for
"hooking" a remote repository. There are hooks, but afaik - like in mw -
only to call e.g. pre and post commit operations. But I doubt that would
make us get rid of the legal aspects anyway.
For inclusion of frameworks I would prefer providing a framework management
that integrates them in one single location for the whole installation. This
would check for version inconsistencies especially for JS fws and make sure
that the same fw is not stored inside multiple extensions which does not
work for different JS fw versions anyway.
All the best,
Achim
Sent from my iPhone
Thanks and regards,
--
Jack Phoenix
MediaWiki developer