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&old=33163@wikia%2Ftrunk%2Flib%2FHTTP) 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.b...@twoonix.com>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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
