aaron@svn.wikimedia.org wrote:
/**
- Additional functions to be performed with updateSpecialPages.
- Expensive Querypages are already updated.
- */
+$wgSpecialPageCacheUpdates = array(
- 'Statistics' => 'SiteStatsUpdate::cacheUpdate'
+);
This is the second time I've seen this, and I'm pretty sure it was from two different authors.
DO NOT use a double-colon to specify calls to static functions!
Use an array instead: array( 'SiteStatsUpdate', 'cacheUpdate' )
Double-colons only work since 5.2.3, which means they may work during development, but they will fail on some Wikimedia servers and on many external installations.
The ONLY place where you should use a double-colon is in $wgHooks. We had to use a double-colon in $wgHooks, with explode() to convert it to an array, because arrays were already used for another purpose (passing parameters).
-- Tim Starling
Double-colons only work since 5.2.3, which means they may work during development, but they will fail on some Wikimedia servers and on many external installations.
Does that mean the Wikimedia servers are not all running identical configurations? That must be a nightmare...
Wikipedia's on 5.2.5 so would be fine with double-colon, but mediawiki.org is only on 5.2.1 and would fail.
Thomas Dalton wrote:
Double-colons only work since 5.2.3, which means they may work during development, but they will fail on some Wikimedia servers and on many external installations.
Does that mean the Wikimedia servers are not all running identical configurations? That must be a nightmare...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thomas Dalton wrote:
Double-colons only work since 5.2.3, which means they may work during development, but they will fail on some Wikimedia servers and on many external installations.
Does that mean the Wikimedia servers are not all running identical configurations? That must be a nightmare...
Yes, there are many different configurations. Yes, it is a nightmare. We thought switching to Ubuntu would make it better, but a year on, our Ubuntu servers still can't do a number of critical tasks, and we now have not only our ancient FC 3 and 4 servers, essentially unmaintained in the vain hope that their existence is temporary, in addition to two different versions of Ubuntu (7.04 and 8.04).
We're running PHP 5.2.5 on the FC apaches, from a source install, and a mixture of 5.2.1 and 5.2.5 on the Ubuntu apaches, from the distro packages. Some search and miscellaneous servers are still running PHP 5.1.x.
-- Tim Starling
On Thu, Sep 04, 2008 at 06:36:15PM +1000, Tim Starling wrote:
Yes, there are many different configurations. Yes, it is a nightmare. We thought switching to Ubuntu would make it better, but a year on, our Ubuntu servers still can't do a number of critical tasks, and we now have not only our ancient FC 3 and 4 servers, essentially unmaintained in the vain hope that their existence is temporary, in addition to two different versions of Ubuntu (7.04 and 8.04).
Would it be a dumb question to ask if anyone considered CentOS 5?
Cheers, -- jra
Jay R. Ashworth wrote:
On Thu, Sep 04, 2008 at 06:36:15PM +1000, Tim Starling wrote:
Yes, there are many different configurations. Yes, it is a nightmare. We thought switching to Ubuntu would make it better, but a year on, our Ubuntu servers still can't do a number of critical tasks, and we now have not only our ancient FC 3 and 4 servers, essentially unmaintained in the vain hope that their existence is temporary, in addition to two different versions of Ubuntu (7.04 and 8.04).
Would it be a dumb question to ask if anyone considered CentOS 5?
Yes it was on the list. Note that the migration problem is not Red Hat versus Debian, rather it's source install versus package. We could have migrated to Ubuntu and used the same source install scripts, slightly modified for the new build environment. But we decided to use packages instead.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling wrote:
Would it be a dumb question to ask if anyone considered CentOS 5?
Yes it was on the list. Note that the migration problem is not Red Hat versus Debian, rather it's source install versus package. We could have migrated to Ubuntu and used the same source install scripts, slightly modified for the new build environment. But we decided to use packages instead.
It is, alas, harder to create and update custom-patched packages than whipping together quickie patch && configure && make && make install scripts.
However packages are usually nicer to deploy, since the package manager can deal with dependencies, and our customized packages don't need to conflict confusingly with the ones in the base distro. New-server installation is faster and easier; particularly for servers which don't maintain state data -- like plain Apache/PHP boxes and Squid proxies -- installation and upgrades are a cinch.
The transitioning of old web servers though is complicated by the way we've mixed text-storage nodes in with the web servers -- we can't simply do a bulk wipe-and-reinstall or we'd lose the data.
This remains a work in progress. We've decommissioned nearly all of the old 32-bit servers (and all of those in the Apache core cluster), leaving us with a consistent x86_64 hardware platform. (Yay!) Mark and Rob have been working on finishing up the software consistency, migrating more of the old Fedora machines as we figure out the best way to do it without breaking text storage.
- -- brion
2008/9/5 Brion Vibber brion@wikimedia.org
It is, alas, harder to create and update custom-patched packages than whipping together quickie patch && configure && make && make install scripts.
However packages are usually nicer to deploy, since the package manager can deal with dependencies, and our customized packages don't need to conflict confusingly with the ones in the base distro. New-server installation is faster and easier; particularly for servers which don't maintain state data -- like plain Apache/PHP boxes and Squid proxies -- installation and upgrades are a cinch.
Why don't you then build custom packages with your patches inside? apt-build and friends (dh_make) should do the trick, at least for Ubuntu.
marco
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marco Schuster wrote:
2008/9/5 Brion Vibber brion@wikimedia.org
It is, alas, harder to create and update custom-patched packages than whipping together quickie patch && configure && make && make install scripts.
However packages are usually nicer to deploy, since the package manager can deal with dependencies, and our customized packages don't need to conflict confusingly with the ones in the base distro. New-server installation is faster and easier; particularly for servers which don't maintain state data -- like plain Apache/PHP boxes and Squid proxies -- installation and upgrades are a cinch.
Why don't you then build custom packages with your patches inside? apt-build and friends (dh_make) should do the trick, at least for Ubuntu.
We do; that's why I described above the various pros and cons of it.
- -- brion
wikitech-l@lists.wikimedia.org