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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l