Re: [Wikitech-l] A Shorturl Service for Wikipedia Projects by Node.js
On Thu, Aug 5, 2010 at 8:57 AM, Mingli Yuan mingli.y...@gmail.com wrote: Now a test server was setup and 5 languages are supported * http://ultrafilter.org:8080/s/cs There is 'n' at top left corner of the screen * http://ultrafilter.org:8080/s/en Working * http://ultrafilter.org:8080/s/he Working * http://ultrafilter.org:8080/s/ml Not working * http://ultrafilter.org:8080/s/zh There is 'nbs' at top left corner of the screen -- സ്നേഹാന്വേഷണങ്ങളോടെ, സാദിക്ക് ഖാലിദ് ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A Shorturl Service for Wikipedia Projects by Node.js
On 8/5/10, Mingli Yuan mingli.y...@gmail.com wrote: Now a test server was setup and 5 languages are supported Special characters are not escaped. Try in the box. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A Shorturl Service for Wikipedia Projects by Node.js
Thanks Liangent and Sadik. Since this list is not the place to discuss bugs, please send your findings at below link http://github.com/mountain/shortify/issues http://github.com/mountain/shortify/issuesThanks very much. On Thu, Aug 5, 2010 at 1:57 PM, Mingli Yuan mingli.y...@gmail.com wrote: Now a test server was setup and 5 languages are supported * http://ultrafilter.org:8080/s/cs * http://ultrafilter.org:8080/s/en * http://ultrafilter.org:8080/s/he * http://ultrafilter.org:8080/s/ml * http://ultrafilter.org:8080/s/zh Thanks for people's contribution to localize this small software: * mountain: Chinese language * svick: Czech language * mountain and Casey: English language * amire80: Hebrew language * Sadik Khalid: Malayalam language If you want to localize more language, please take a look of the file http://github.com/mountain/shortify/blob/master/config/i18n.js Clone and patch to me on github, or send me the patch directly via mail. http://github.com/mountain/shortify Thanks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Custom editor hooks
On Thu, Aug 5, 2010 at 07:04, Daniel Friesen li...@nadir-seen-fire.com wrote: 1) I use the EditPageBeforeEditChecks hook to add a checkbox to disable MeanEditor. However, I also need to set it to the correct value. Right now, I am overriding the entire showStandardInputs function just to change line 1749 (referring to http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_16/phase3/includes/EditPage.php). Am I missing an obvious solution here? You talking about the $checked values passed by showStandardInputs? I think that was probably just there for legacy or to cleanly separate values from that method, I can't remember. But all getCheckboxes uses that for is passing booleans, can't you just supply the checkbox value directly in your hook? Yes, it works. I was trying to replicate the functionality of the minoredit checkbox (read from preference the first time, keeps the user-selected value after that), so I was only looking at that. I now set the initial value during importFormData, that's probably the right place to do so. 2) I would like to disable the default toolbar when the visual editor is in use. In the past, I used to override the entire showEditForm method and reset the $toolbar variable. How can I accomplish this now? Ouch, it would have been nicer for you if getEditToolbar was not static. And perhaps also if the two should I show the toolbar tests were broken into another instance method. I think you might be able to use EditPageBeforeEditToolbar to erase the toolbar though. It works, thanks for the suggestion. 3) I need to add the 'wymupdate' class to the standard buttons (submit, preview, diff, etc.). Is there a clean way to do this without overriding the entire getEditButtons method? Hmm, that makes me think getEditButtons would have been better to use an assoc-array where the contents were arguments to Xml::element so it could be overridden instead of straight html. I can't think of a non-ugly way to do this. You could almost override getEditButtons, call the superclass method, and for each input use a regex to insert a class manually... though that IS ugly. Well, for now I will just replicate the method, it's quite short and the modification is easy. @Platonides: the .wymupdate selector is hardcoded into WYMeditor. I prefer to leave WYMeditor untouched, so that I/users can use another version, custom plugins, etc. Thanks for your answers -- Jacopo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is thers a extension to implement a cornell notes
* 尹永宏 yinyongh...@gmail.com [Wed, 4 Aug 2010 16:39:32 +0800]: Hi all I'm looking for a extension to implement a cornell notes( http://en.wikipedia.org/wiki/Cornell_Notes). do you have any idea? I haven't heard about such extension. However, I've read wikipedia article you mentioned, and it seems that you can imitate this notation by using templates with tables (keywords column, notes column), or, even, trying to use Semantic Forms to build a set of keywords/notes fields then output these with #ask queries. MediaWiki is not actively pushed to be used as CMS, yet. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New table: globaltemplatelinks
We are having more and more global uses. We should have a global namespace mapping so that each global table doesn't need to copy the namespace names just for display. Maybe, but that's not easy. Storing the namespace name sounds like an acceptable intermediate solution. It would be a dependence for all global extensions, but why would that be difficult? I think we just need to store: * the wikiid * the namespace (int) * the namespace text for each namespace of each wiki, in a shared database (with an index :D) I will first code my stuff as planed and then, if I still have some time, create this new table and adapt my code to use it. I have updated the proposal after a discussion with Roan: we think that using a shared table with all the interwiki transclusion links would be much more practical, especially when we need to update it when a calling page is edited/deleted/moved... Can you please have a look at it again? Thanks -- Peter Potrowl http://www.mediawiki.org/wiki/User:Peter17 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 03/08/10 00:16, Lane, Ryan wrote: Please Debian, keep your version of MediaWiki up to date at least to the oldest stable release, and please send your fixes upstream when you find unfixed bugs. Debian Stable is stable in the sense that it doesn't change very often, it's not stable in the sense of fewer bugs. If there was a way to fix this, it would have been done a long time ago. Debian is a weird, bureacratic, conservative community, somewhat inscrutable to outsiders. It reminds me of Wikipedia. On 04/08/10 02:45, Niklas Laxström wrote: On 3 August 2010 18:14, Aryeh Gregor simetrical+wikil...@gmail.com wrote: I'm thankful that the Debian MediaWiki package at least *works*. Not that the same can be said of all their packages either (OpenSSL, anyone?). Maybe if we provided .debs and RPMs, people would be less prone to use the distro packages. That just creates more problems: * bad quality distro packages * bad quality our own packages (while we know MediaWiki, we are not experts in packaging) * lots of confusion Last time I looked at our Debian package, it was pretty bad. The custom patches were mostly unnecessary, or could be made unnecessary with a one-line hook, incorporated upstream. However, the worst thing about it was the fact that after you installed it, you then had to run the web-based installer, typing some very specific things into the database fields, in order to make it work. Installing the package only installs the files, and upgrading the package only upgrades the files, neither operation will touch the database. I decided that to fix the Debian package, there were two basic things that needed to happen: 1) Write a new installer, that makes it possible for dpkg to trigger DB installs and upgrades. 2) Build a relationship with the Debian maintainer, and in time, perhaps take over their job. Item 1 was my motivation to start the new-installer branch, but I didn't really get close to finishing it. Luckily some other people have picked up the ball and we might see it in 1.17, although the dpkg interface will probably have to wait until later. Item 2 would be a procedure along the lines of: * Write a new package that uses the features of the new installer. * Ask the maintainer to upload this version, explaining how awesome it is. * Integrate Debian package generation into the make-release script. * After each minor release, nag the maintainer to apply the automatically generated patches. * When they get sick of that, ask them to sponsor your request for Debian Developer status. * Upload new packages to Debian on each new release. The main targets would be Unstable, Testing and Ubuntu Universe. I think Stable is mostly unfixable and not worth bothering with. I've written a few dpkg packages for Wikimedia's custom repository. It's tedious, there's a steep learning curve, but I don't think it's beyond the capabilities of our core dev team. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
On 03/08/10 00:01, Jacopo Corbetta wrote: I haven't read all the documents, but have these researchers taken into account backported fixes? No. Their work mostly revolves around defeating version number obfuscation by correlating various properties of the application with the version number. They scanned the Internet to demostrate that their method works, and presented the version number distribution in passing. The security conclusions they drew from that distribution were not particularly rigorous. My gut feeling is that the preference for 1.12 is simply due to its inclusion in Debian stable [1]. They mention seeing spikes in popularity for packaged versions. The maintainer seems to be actively backporting security fixes [2], so while I agree that these versions may enjoy less community support, they should not be considered broken on the basis of the version number alone. It's true that backports reduce the problem somewhat. But note that the Debian backports have probably not been reviewed to make sure that they fix the bugs they claim to fix. Or indeed, that they don't create new bugs that are even worse (as Kurt Roeckx did with his famous fix for some spurious valgrind warnings in OpenSSL). -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
On Thu, Aug 5, 2010 at 10:13 AM, Tim Starling tstarl...@wikimedia.org wrote: Or indeed, that they don't create new bugs that are even worse (as Kurt Roeckx did with his famous fix for some spurious valgrind warnings in OpenSSL). The onus isn't 100% on Debian, partial blame can be on the OpenSSL team for not saying Hey that's a stupid idea when he asked about his 'fix'. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Selenium Framework - Question on coding conventions
Hello everybody, in order to further develop the selenium framework [1], I need to make a few design decisions, especially on coding conventions, which I'd like to discuss on this list, since they affect the way of how extension- and core developers write their tests. 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that is extensiondir/tests/selenium. 2) How are the tests organized? Tests are organized in testing suites. Each suite represents a conhesive set of tests. So it is possible to have more than one test suite per extension / core area. Test suites are technically classes. The files should follow this naming convention: NameOfExtension[Subset]TestSuite.php. The subset is optional. For example, in the PagedTiffHandler extension, it would be PagedTiffHandlerTestSuite.php and PagedTiffHandlerUploadsTestSuite.php. This should also be the name of the class. Alternatively, we could use the word Selenium somewhere in there in order to be able to divide between unit and selenium tests. In that case I suggest to use PagedTiffHandlerSeleniumTestSuite.php and PagedTiffHandlerUploadsSeleniumTestSuite.php. Hmmm... this gives pretty long names. Any suggestions? 3) How does the framework know there are tests? The tests should be registered with the autoloader in the extension entry file. In core, they should be registered directly with the autoloader. 4) Which tests should be executed? Since Selenium tests are slow, not every test should be executed in each test run. So At the moment, there is a variable $wgSeleniumTestSuites which can be set in LocalSettings.php and which contains the tests that should be run. If things become more dynamically (e.g. when tests should be run on svn commit), there could be a function to add to this variable. 5) Aesthetics... There is an awful lot of Selenium in the class names, method names, file names and variable names. It might be a good idea to use Sn everywhere except for path names. Two things need to be kept in mind: * The idea is to use a similar structure for unit- and selenium tests (selenium tests are based on unit tests anyway). I assume at some point, the tests should also be compatible with a continuous integration server. * The wiki that executes the selenium tests is not neccesarily the one that is being tested if the tests run against a selenium grid. If anybody would like to share their opinion on my suggestions, I'd be very glad! Regards, Markus [1] http://www.mediawiki.org/wiki/SeleniumFramework (documentation will be updated soon..) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - Question on coding conventions (wican: to exclusive)
On 08/05/2010 12:37:01 PM, Markus Glaser - gla...@hallowelt.biz wrote: Hello everybody, snip 5) Aesthetics... There is an awful lot of Selenium in the class names, method names, file names and variable names. It might be a good idea to use Sn everywhere except for path names. Shortening the name is a good idea. Since Selenium is a chemical element, I think would be less confusing if you used the element abbreviation. Sn is Tin (stannum), Se is Selenium. Jim Laurino snip... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Testing Framework (was Selenium Framework - Question on coding conventions)
Markus Glaser gla...@hallowelt.biz writes: 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that is extensiondir/tests/selenium. Sounds fine. In the same way, since maintenance/tests contains tests that should be run using PHPUnit, we can say that extensiondir/tests will contain tests that should be run using PHPUnit. Alternatively, we could use the word Selenium somewhere in there in order to be able to divide between unit and selenium tests. I think putting them in the selenium directory (or the “Se” directory) is sufficient. 3) How does the framework know there are tests? Can I suggest that the framework can see that an extension has tests simply by the presence of the extensiondir/tests directory containing a Extension*TestSuite.php file? The extensiondir/tests/ExtensionTestSuite.php file should define a class using the name ExtensionTestSuite which has a static method suite(). See the PHPUnit documentation at http://bit.ly/b9L50r for how this is set up. This static suite() method should take care of letting the autoloader know about any test classes so the test classes are only available during testing. So, for your example using PagedTiffHandler, there would be the files: PagedTiffHandler/tests/PagedTiffHandlerTestSuite.php PagedTiffHandler/tests/PagedTiffHandlerUploadsTestSuite.php 4) Which tests should be executed? By default all the test suites in extensiondir/tests should be run. It is should be possible to specify which particular test to run by using whatever command line arguments to the CLI. This seems better to me than defining a new global. If some tests should only be run rarely, that information can be put in the TestSuite class for te extension. In this way, I think it is possible to remove all the $wgSelenium* variables from the DefaultSettings.php file. (I plan to do something similar with the $wgParserTest* variables as well — these sorts of things don't seem like they belong in Core.) Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing Framework (was Selenium Framework - Question on coding conventions)
On Thu, Aug 5, 2010 at 6:47 PM, Mark A. Hershberger m...@everybody.org wrote: Markus Glaser gla...@hallowelt.biz writes: 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that is extensiondir/tests/selenium. Sounds fine. In the same way, since maintenance/tests contains tests that should be run using PHPUnit, we can say that extensiondir/tests will contain tests that should be run using PHPUnit. I would prefer moving them to a subdirectory of /tests/. As we hopefully amass more unit tests, keeping them in the top-level will get a bit confusing when trying to distinguish them from supporting code (shared setUp and tearDown code, the bootstrap stuff, etc) Something like /maintenance/tests/unit/ to mirror /maintenance/tests/ selenium/ would make the most sense. Consistency and thinking ahead is nice :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
David Gerard wrote: On 3 August 2010 00:17, Edward Z. Yang ezy...@mit.edu wrote: 2. Distributors roll patches without telling upstream developers who would happily accept them into the mainline. Has anyone reported the following as Debian bugs? * Package maintainer not sending patches back upstream * Package maintainer not visible and active in MediaWiki development * Package maintainer not visible and active in MediaWiki community support, leaving supporting his packages to the upstream - d. In fact, one of their patches was sent upstream a couple of months ago and we didn't react to it. https://bugzilla.wikimedia.org/show_bug.cgi?id=24132 It's a documentation patch, fine as it is, although i'd prefer to fix that by moving dumpBackup to the new Maintenance style. Other patches are not so fine... wfSuppressWarnings(); - session_start(); + @session_start(); wfRestoreWarnings(); Sure, it was for FusionForge package, but still what error would session_start produce that is not trapped? (I can only make an E_NOTICE or E_WARNING...) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
My idea for a FHS-friendlier setup was based in storing the LocalSettings for all installed wikis inside /etc/mediawiki.d, all of them pulling from a CommonSettings.php where default overrides and extensions affecting all installs would be stored. The update process would just need to iterate on them running update.php Then for the installer we could ask the user to overwrite a file with the download, overwrite it ourselves from the web installer or create another installer, this one to be run from command line by dpkg. Does anyone see a problem with that approach? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On 06/08/10 09:10, Platonides wrote: My idea for a FHS-friendlier setup was based in storing the LocalSettings for all installed wikis inside /etc/mediawiki.d, all of them pulling from a CommonSettings.php where default overrides and extensions affecting all installs would be stored. That's basically what it does already, but it does it by patching the setup code. I'd rather see a distributed LocalSettings.php file which pulls in the necessary sub-config files. That can be done without any changes to our source. The update process would just need to iterate on them running update.php Then for the installer we could ask the user to overwrite a file with the download, overwrite it ourselves from the web installer or create another installer, this one to be run from command line by dpkg. Does anyone see a problem with that approach? The web installer should not be a part of installation from a package at all. We should just get the wiki name from debconf, use the system locale as the language, and install it with defaults otherwise. Then the user will have a working wiki after install. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Flash and other proprietary technologies on Wikimedia projects
Guillaume Paumier wrote: I don't think there is an official Board resolution about the use of proprietary technologies on Wikimedia projects. However, Brion and Erik have been known to have a pretty strong opinion on that, and I believe Danese and a large part of the WMF tech staff are in the same place. A few relevant links for a historical perspective: * We should permit Flash video playback thread on foundation-l in 2007 http://thread.gmane.org/gmane.org.wikimedia.commons/2220/ * Software policy draft thread on foundation-l in 2007 http://thread.gmane.org/gmane.org.wikimedia.foundation/19547/ * The actual draft: http://meta.wikimedia.org/wiki/Wikimedia_Draft_Statement_of_Principles_Regarding_Software_Use There is nothing in that, or in http://meta.wikimedia.org/wiki/File_format_policy which suggests that we can't use Flash for microphone audio upload, is there? Are people aware of http://haxe.org/doc/intro and http://www.gnu.org/software/gnash/ ? The bulk of Flash is no longer proprietary. I know there are patent issues around some flash video formats, but at this point I have little confidence that any of the major browser authors will provide HTML microphone upload in the next five years. Is there any reason to believe otherwise? Casey Brown wrote: Another, somewhat more recent one: http://wikimediafoundation.org/wiki/Minutes/October_3-5,_2008#Open_Standards_.2F_Free_File_Formats The board asked Sue to have Mike Godwin revise the draft policy to a version that would make it clear that only free formats are permissible. Did that ever happen? (Or did anything useful ever come about of it?) Clearly not, so I am asking Sue and Mike directly by adding them as addressees. I have been working on microphone audio upload since before the previous decade: http://www.w3.org/TR/device-upload -- I have also offered to donate some nice ActionScript microphone upload code to the Foundation which compiles with Haxe if the builder is willing to do such things as replace the Speex vocodec constant with the equivalent integer. It doesn't run under gnash yet, but I believe it will soon. (I don't think there would be consensus for dropping Wikimedia support for closed-source browsers, as a related matter.) In return, I have asked the Foundation to spend $2,500 on a contract with Yaron Koren to enable GIFT -- http://microformats.org/wiki/gift -- in the Quiz extension. That would be particularly useful if the efforts to ask the Open University to re-license the several thousand hours of courseware which they currently publish under cc-by-nc-sa, to cc-by-sa or cc-by succeed. I have asked multiple parties, including Board members and the UK Chapter to work on that simultaneously. I believe at least two of them are working on that effort. In any case, GIFT is far more compact and more wikitext-like than the existing Quiz extension to Mediawiki which is bulky and suffers from lack of use in more than 90 assessments on Wikiversity, for example, while GIFT assessments can be produced from the assessments in any Moodle course using Moodle's export function. However, even though Wayne Mackintosh of the 25,000 teacher-strong WikiEducator and OER Foundation wrote to Erik back on March 28, saying they were very supportive of the GIFT compatibility project, Erik has so far hesitated, saying that he wants to see additional support from the community. So please, if you think GIFT assessment support and/or Flash microphone audio upload is a good idea (and I would repeat that the Spanish Wiktonary still has no audio pronunciation for hola even though the English Wiktionary does) then please let Erik know. Thank you! Sincerely, James Salsman ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ExtensionDistributor
Hey, I figured I can use the same code as ExtensionDistributor for creating packages for the deployment extensions. The code for creating archives and going through the svn repo is not in the extensions directory on svn as far as I can determine though. Where can I find it? If it's not publicly available anywhere at the moment, can it be made so? Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Hoi, In addition to all that it makes sense to have LocalisationUpdate installed and configured. It ensures that people who opt for another language then English have the latest available localisations for the messages on their wiki. Thanks, GerardM On 4 August 2010 19:04, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Tue, Aug 3, 2010 at 9:03 PM, Rob Lanphier ro...@robla.net wrote: +1 for package maintainer education (as frustrating and unproductive as it might be thusfar) I think education isn't a good term for what needs to happen here. More like doing the work for them. Package maintainers might maintain lots of packages, and certainly don't know much about any of them. Some MW developer needs to look at the popular distros, read up on their packaging standards, and make a MediaWiki package that a) meets the standards, but also b) actually works and is supported upstream. Keep any packaging tools in our own SVN where that makes sense, so the distributor can ship software with absolutely no changes if they like. And give them some contacts they can forward any patches to, so that hopefully that don't feel the need to accept patches that haven't been reviewed upstream. As I remarked on IRC, having packages as an official installation mechanism has nice benefits for people who don't get their code from distros, too. We could set up our own official repository. This would handle updates automatically, but it would do more than that too. Our current installer is crippled in all sorts of ways because it has to run as the web user. An installer that runs as root could do all sorts of handy things, particularly where permissions are an issue: * Enable uploads by default * Hide deleted images properly * Enable $wgCacheDirectory by default * Enable math by default * Enable clamav by default (maybe :) ) * Enable Djvu and SVG support by default * Enable ImageMagick by default * Set up cron job to run jobs by default instead of hacky running on page view We'd likely want to provide packages for all the extensions in SVN too, somehow. This is complicated by the fact that almost none of the extensions are actually released independently. Maybe that should change somehow. On Wed, Aug 4, 2010 at 8:48 AM, Lane, Ryan ryan.l...@ocean.navo.navy.mil wrote: It's special. It isn't necessarily the fault of the distro or the package maintainer for the quality of the packages. It is our fault. Upgrading is unreliable for a number of reasons. It is definitely unreliable enough that I wouldn't trust a package to do it for me, and I can't reasonably recommend it for anyone else either. Upgrading is perfectly reliable in my experience, as long as all your extensions are reliable, and you upgrade them too. If people do file edits, or they install weird extensions, then of course upgrades might break stuff. But if you're using only well-supported extensions, there should be no major problems in most cases. If there are, well, that's what distributions have testing for! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
