Hoi, We are building a test environment to test MediaWiki and its extensions. We aim to provide information on what extensions can be expected to work in what environment. When extensions are found not to work, it should be possible to fix the problem. We found for instance that the Babel extension did not work on an older version of PHP, the code was backported and consequently it needed a new revision that it got.
Today I was struggling with the CrossNamespaceLinks. I tried to install the revision that is advertised on the English Wikipedia 37404 and it broke MediaWiki. An essential file was not part of the extension. I installed the extension without specifying the revision, it worked and it advertised itself as revision 37404.
I was building an environment with the new ie current Wikipedia software configuration. There are many valid arguments why it should be possible to reliably rebuild the software environment. One of them is to test the software. When installing an extension like CrossNamespaceLinks is a dark art, it is not valid to say in its documentation that it is stable software because the WMF runs it for a long time.
In my opinion the ability to be able to reliably install MediaWiki and its extensions, the ability to rebuild an Open Content environment is what demonstrates the quality of the software. This quality is what enables people, organisations to use MediaWiki in a stable environment. Providing this level of quality will bring more people to use our software, to help with the localisation of our software to enlarge the ecosystem that is building around our software and around the wiki concept.
My suggestion is to define and implement best practices for extensions and test extensions and their revisions for their functionality. Our testing environment is available for this. I will be happy to demonstrate it in Berlin. Thanks, GerardM
2008/12/31 Brion Vibber brion@wikimedia.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Special:Version displays SVN version numbers for extensions out of $wgExtensionCredits, which seems to be done with $LastChangedRevision$ keywords in the extension's entry point file.
This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected.
If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki.
But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful.
Anybody have a suggestion on how to best handle this?
- -- brion
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklb6VcACgkQwRnhpk1wk44MNACg2c0ztpocjHfsb5l+KxSu8e+I wXgAoMSrjFeTPzEnMY4904bxXZv+DiYf =GNqG -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l