Re: [Wikitech-l] Github Extensions
On 02/07/2013 03:14 AM, MZMcBride wrote: Sure, I picked Gists. It didn't seem like a very difficult choice. All cleaned up (redirected) now. I don't think that makes sense. If someone has a link to http://www.mediawiki.org/wiki/Extension:Gist from a README or something, they're now going to a different extension. You can propose deleting the others, but I think the redirects are somewhat misleading. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Github Extensions
Matthew Flaschen wrote: On 02/07/2013 03:14 AM, MZMcBride wrote: Sure, I picked Gists. It didn't seem like a very difficult choice. All cleaned up (redirected) now. I don't think that makes sense. If someone has a link to http://www.mediawiki.org/wiki/Extension:Gist from a README or something, they're now going to a different extension. You can propose deleting the others, but I think the redirects are somewhat misleading. The confusion caused by having three almost identical extensions (particularly Gist v. Gists) far exceeds the confusion caused by the redirects (or broken links, if we deleted the documentation, as you suggest). Even if we deleted the other extensions, both Extension:Gist and Extension:GitHub are completely reasonable and warranted redirects to Extension:Gists, putting us exactly back to where we started. I've re-reverted your edits and added a note to the page explaining that the other extensions were redirected/merged. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Documentation talk, the second
Everyone knows your phone is more powerful than half of production cluster, but now back to the business We should make a structure for this new documentation base we are going to create, I think beside of categories, they might be some spaces at least Documentation: or something like that, where we could put stuff, and it should be divided to: Wikimedia operation (what is now mostly on wikitech) - cluster a -- server 1 -- server 2 etc - cluster b... ... Wikimedia labs - project A -- instance A-1 -- instance A-2 ... Wikimedia bots - bot A -- developer docs (for devs) -- operation docs (for ops) -- user manuals (for end users) Wikimedia tools - tool A -- developer docs (for devs) -- operation docs (for ops) -- user manuals (for end users) other stuff this is my proposal, of course it could be done in a different way but we should make a final decision before we start importing stuff or we create a mess On Wed, Feb 6, 2013 at 10:55 PM, Antoine Musso hashar+...@free.fr wrote: Le 06/02/13 20:39, Petr Bena a écrit : Hi, this is a second time I am opening this - last time we decided to merge wikitech and labsconsole to make a documentation base for developers and operation engineers (at least those working at labs - I consider operation of bots and such services operation as well). snip I will be glad to help on this! Make sure to keep the history by importing the articles :-] Trivia: did you know we used to have three squids in Paris? My phone is more powerful than the hardware that was setup there :) https://wikitech.wikimedia.org/view/Lopar_cluster -- Antoine hashar Musso ___ 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
Re: [Wikitech-l] Comparisons to Confluence (was Minimalist MediaWiki? (was Re: Merge Vector extension into core))
Hey, For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base. This is not something WMF is interested in doing, that has been made extremely clear in the last year. Agree, I also think this is the main issue, and know other people active with MW outside WMF think the same. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC: Standardized thumbnails sizes
Hello, Wikitext editors can have media materials rendered using any arbitrary size (the thumbnails wikitext syntax). Each different size would produce a hit to the server backend which will generate a thumbnail for that size. The following requests for comment is about having a consistent set of thumbnails sizes that are allowed to be rendered and let the client browser to do the up or down scaling. https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes It would be nice to discuss about it on the list and amend the document with any idea you might have :-] -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: Standardized thumbnails sizes
On 7 February 2013 11:37, Antoine Musso hashar+...@free.fr wrote: The following requests for comment is about having a consistent set of thumbnails sizes that are allowed to be rendered and let the client browser to do the up or down scaling. https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes This should probably also be noted on the other lists and the WMF wikis affected. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] RFC: Introducing two new HTTP headers to track mobile pageviews
On Feb 6, 2013, at 9:32 PM, David Schoonover d...@wikimedia.org wrote: Just want to summarize and make sure I've got the right conclusions, as this thread has wandered a bit. *1. X-MF-Mode: Alpha/Beta Site Usage* * * We'll roll this into the X-CS header, which will now be KV-pairs (using normal URL encoding), and set by Varnish. This will avoid an explosion of cryptic headers for analytic purposes. Questions: - It seems there's some confusion around bypassing Varnish. If I understand correctly, it's not that Varnish is ever bypassed, just that the upstream response is not cached if cookies are present. Is that right? Yes - Since we're repurposing X-CS, should we perhaps rename it to something more apt to address concerns about cryptic non-standard headers flying about? I'd like to propose to define *one* request header to be used for all analytics purposes. It can be key/value pairs, and be set client side where applicable. Varnish can append to it where needed, later keys overriding earlier ones. Then we can log that one header across all HTTP/caching clusters without having to change the log stream all the time, and without wasting much space, and caching edge configuration changes are kept to a minimum as well. And we might as well be transparent in its naming. header name Log-Parameters:? *2. X-MF-Req: Primary vs Secondary API Requests* This header will be replaced with a query parameter set by the client-side JS code making the request. Analytics will parse it out at processing time and Do The Right Thing. I think the question of using a URL param vs a request header should mainly take into account whether the response varies on the value of the parameter. If the responses are otherwise identical, and the value is only used for analytics purposes, I would prefer to put that into the above header instead, as it will impair cacheability / cache size otherwise (even if those requests are currently not cacheable for other reasons). If the responses are actually different based on this parameter, I would prefer to have it in the URL where possible. -- Mark Bergsma m...@wikimedia.org Lead Operations Architect Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Documentation talk, the second
On Thu, Feb 7, 2013 at 2:29 AM, Petr Bena benap...@gmail.com wrote: Everyone knows your phone is more powerful than half of production cluster, but now back to the business We should make a structure for this new documentation base we are going to create, I think beside of categories, they might be some spaces at least Documentation: or something like that, where we could put stuff, and it should be divided to: Wikimedia operation (what is now mostly on wikitech) - cluster a -- server 1 -- server 2 etc - cluster b... ... I'm in favor of just not importing the server docs. There may be a couple of ops folks this don't agree with me here, though. Wikimedia labs - project A -- instance A-1 -- instance A-2 ... I'm in favor of heavily refactoring the project pages. They haven't really had much love since they were introduced. Can you give more of an idea of how this would work? At minimum I'd like to move the projects out of the Nova_Resource namespace. Wikimedia bots - bot A -- developer docs (for devs) -- operation docs (for ops) -- user manuals (for end users) Wikimedia tools - tool A -- developer docs (for devs) -- operation docs (for ops) -- user manuals (for end users) other stuff this is my proposal, of course it could be done in a different way but we should make a final decision before we start importing stuff or we create a mess Documenting tools and bots this way seems sane to me. BTW, for all of this, are you describing pages with subsections, or lots of subpages? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Documentation talk, the second
I think subsections are fine as long as they are small, for long pages, it would be better to have it as subpage. But TBH I would prefer the subpages everywhere, you can always create some index page that would include the subpages to subsections. On Thu, Feb 7, 2013 at 2:16 PM, Ryan Lane rlan...@gmail.com wrote: On Thu, Feb 7, 2013 at 2:29 AM, Petr Bena benap...@gmail.com wrote: Everyone knows your phone is more powerful than half of production cluster, but now back to the business We should make a structure for this new documentation base we are going to create, I think beside of categories, they might be some spaces at least Documentation: or something like that, where we could put stuff, and it should be divided to: Wikimedia operation (what is now mostly on wikitech) - cluster a -- server 1 -- server 2 etc - cluster b... ... I'm in favor of just not importing the server docs. There may be a couple of ops folks this don't agree with me here, though. Wikimedia labs - project A -- instance A-1 -- instance A-2 ... I'm in favor of heavily refactoring the project pages. They haven't really had much love since they were introduced. Can you give more of an idea of how this would work? At minimum I'd like to move the projects out of the Nova_Resource namespace. Wikimedia bots - bot A -- developer docs (for devs) -- operation docs (for ops) -- user manuals (for end users) Wikimedia tools - tool A -- developer docs (for devs) -- operation docs (for ops) -- user manuals (for end users) other stuff this is my proposal, of course it could be done in a different way but we should make a final decision before we start importing stuff or we create a mess Documenting tools and bots this way seems sane to me. BTW, for all of this, are you describing pages with subsections, or lots of subpages? - Ryan ___ 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
Re: [Wikitech-l] [Engineering] RFC: Introducing two new HTTP headers to track mobile pageviews
I'd like to propose to define *one* request header to be used for all analytics purposes. It can be key/value pairs, and be set client side where applicable. Varnish can append to it where needed, later keys overriding earlier ones. Then we can log that one header across all HTTP/caching clusters without having to change the log stream all the time, and without wasting much space, and caching edge configuration changes are kept to a minimum as well. Agreed. Instrumentation should ideally never get in the way of production performance, so if we can cut or optimize header use for logging without being too onerous, we'll happily do so. afaik, the reasons that custom HTTP headers are used at all are: - They're accessible from varnishncsa without code modifications; - Varnish and/or other parties in the request chain can munge the values prior to logging to save bytes (examples being X-CS, which replaces the semantic carrier name with a [vastly shorter] numeric code, and the proposed X-MF-Mode header, which prevents the need to log the whole cookies header for post-processing). Ideally, none of this should need to make a trip to the client. I don't recall seeing anything in the Varnish docs providing a way to send values exclusively to the loggers, but if there is, that's an easy win, and it wouldn't require any changes to our parsing pipeline. If that's not possible, it makes sense to collapse various headers into a KV field; that would require changes on our side, including all downstream consumers of the log stream (which is surprisingly large), so it's not a trivial move. -- David Schoonover d...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Github Extensions
I should also point out that the likelihood of any links pointing to either of the other two extensions is very low, considering neither have README files (both had their code on the page) and only the GitHub extension even had the extension page URL in the extension description. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Feb 7, 2013 at 4:25 AM, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/07/2013 03:14 AM, MZMcBride wrote: Sure, I picked Gists. It didn't seem like a very difficult choice. All cleaned up (redirected) now. I don't think that makes sense. If someone has a link to http://www.mediawiki.org/wiki/Extension:Gist from a README or something, they're now going to a different extension. You can propose deleting the others, but I think the redirects are somewhat misleading. The confusion caused by having three almost identical extensions (particularly Gist v. Gists) far exceeds the confusion caused by the redirects (or broken links, if we deleted the documentation, as you suggest). Even if we deleted the other extensions, both Extension:Gist and Extension:GitHub are completely reasonable and warranted redirects to Extension:Gists, putting us exactly back to where we started. I've re-reverted your edits and added a note to the page explaining that the other extensions were redirected/merged. MZMcBride ___ 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
[Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
(Added MW-Enterprise mailing list) On 02/06/2013 10:00 PM, Tim Starling wrote: For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base. Totally agreed. I (along with a few other hardy volunteers) have been helping MW users at [[mw:Project:Support desk]] and it seems clear that the focus most developers have on the WMF use case has really made MW less usable for other people. One of my clients had an older (1.11) MediaWiki installation that they are using to share information with their distributors world-wide. Their first attempt to get the system to do what they wanted was a flop since the Java developer they had working on the system really didn't know that much about MW. I was able to get the system upgraded to 1.19 and adapt MW to their infrastructure using hooks, ResourceLoader, and pages they could update in the MediaWiki namespace. So, yes, I think MediaWiki has a lot to offer corporate users, but we haven't really made that clear or shown them how to do a lot of things they want to do. Tim has it right when he says MediaWiki needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. We've discussed this sort of thing over and over, but I think we're actually beginning to make some headway now thanks especially to work by Mariya Miteva. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
On 02/06/2013 10:00 PM, Tim Starling wrote: For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base. I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia: The main reason we chose Confluence was lack of Totally agreed. I (along with a few other hardy volunteers) have been helping MW users at [[mw:Project:Support desk]] and it seems clear that the focus most developers have on the WMF use case has really made MW less usable for other people. One of my clients had an older (1.11) MediaWiki installation that they are using to share information with their distributors world-wide. Their first attempt to get the system to do what they wanted was a flop since the Java developer they had working on the system really didn't know that much about MW. I was able to get the system upgraded to 1.19 and adapt MW to their infrastructure using hooks, ResourceLoader, and pages they could update in the MediaWiki namespace. So, yes, I think MediaWiki has a lot to offer corporate users, but we haven't really made that clear or shown them how to do a lot of things they want to do. Tim has it right when he says MediaWiki needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. We've discussed this sort of thing over and over, but I think we're actually beginning to make some headway now thanks especially to work by Mariya Miteva. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ 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
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
Sorry about that - Gmail reload glitch On 02/06/2013 10:00 PM, Tim Starling wrote: For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base. I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned): http://www.theregister.co.uk/2007/03/13/disney_eisner/ http://family.go.com/parenting/ The main reasons we chose Confluence: * An easier to understand API. This seems to not be a problem any more: http://www.mediawiki.org/wiki/API:Client_code * Easier setup on Windows: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki Do we have a place where people can talk through problems with corporate adoption? I suspect Tim's correct about the general case but that focusing on specifics would drive adoption. Dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
Hi Dan, We have http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion where we've been discussing some MW user issues, but the dicussion was not focused on corporate per se. We can use the same page or maybe set up a subpage if you think it will be easier. There is also https://www.mediawiki.org/wiki/Enterprise_hub. If anyone know of another appropriate place, please share. I would be glad to see such a space set up and discussion going on and would be happy to assist with that. Mariya On Thu, Feb 7, 2013 at 7:06 PM, Dan Andreescu dandree...@wikimedia.orgwrote: Sorry about that - Gmail reload glitch On 02/06/2013 10:00 PM, Tim Starling wrote: For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base. I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned): http://www.theregister.co.uk/2007/03/13/disney_eisner/ http://family.go.com/parenting/ The main reasons we chose Confluence: * An easier to understand API. This seems to not be a problem any more: http://www.mediawiki.org/wiki/API:Client_code * Easier setup on Windows: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki Do we have a place where people can talk through problems with corporate adoption? I suspect Tim's correct about the general case but that focusing on specifics would drive adoption. Dan ___ 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
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
On 7 February 2013 17:06, Dan Andreescu dandree...@wikimedia.org wrote: I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned): The main reasons we chose Confluence: * An easier to understand API. This seems to not be a problem any more: http://www.mediawiki.org/wiki/API:Client_code * Easier setup on Windows: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki yeah, I was speaking from my experience of MW vs Confluence, where the deciders were (1) no WYSIWYG and slightly (2) none of the fancy ACL stuff Confluence has. The ACLs were more a theoretical selling point to the business decision maker, but WYSIWYG swung it I think. And the users *hated* Confluence, but at least they didn't have to deal with Wikitext. (In my current job I'm happily spreading MediaWikis far and wide, albeit with very little customisation. But I'm really keen to use the Visual Editor as soon as it's in a tarball version.) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
On Thu, Feb 7, 2013 at 11:45 AM, David Gerard dger...@gmail.com wrote: (In my current job I'm happily spreading MediaWikis far and wide, albeit with very little customisation. But I'm really keen to use the Visual Editor as soon as it's in a tarball version.) Yes, that is the prime reason we're still on 1.17 at work, it's the most recent version the FCKEditor extension works on. Soon as there's something equivalent for current versions they *might* consider upgrading. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia engineering January 2013 report
Hi, The report covering Wikimedia engineering activities in January 2013 is now available. Wiki version: https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2013/January Blog version: https://blog.wikimedia.org/2013/02/07/engineering-january-2013-report/ We're also proposing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge: https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2013/January/summary Below is the full HTML text of the report, as previously requested. As always, feedback is appreciated about the usefulness of the report and its summary, and on how to improve them. -- Major news in January include: - the successful migration of our main serviceshttps://blog.wikimedia.org/2013/01/19/wikimedia-sites-move-to-primary-data-center-in-ashburn-virginia/to our data center in Ashburn, Virginia; - new featureshttps://blog.wikimedia.org/2013/01/11/mobile-beta-a-sandbox-for-new-experimental-features/available in our mobile beta; - progress on input methodshttps://blog.wikimedia.org/2013/01/25/language-engineering-progress-with-input-methods-and-translation-editor/and our upcoming translation interfacehttps://blog.wikimedia.org/2013/01/11/a-more-efficient-translation-interface/ ; - the announcement of GeoDatahttps://blog.wikimedia.org/2013/01/31/geodata-a-new-age-of-geotagging-on-wikipedia/, a feature to attach geo-coordinates to Wikipedia and Wikivoyage articles; - a testing event to assess how VisualEditor handles non-Latin charactershttps://blog.wikimedia.org/2013/01/28/help-us-test-and-investigate-visualeditor/ . *Note: We're also proposing a shorter, simpler and translatable version of this reporthttps://www.mediawiki.org/wiki/Wikimedia_engineering_report/2013/January/summarythat does not assume specialized technical knowledge. * Personnel Work with us https://wikimediafoundation.org/wiki/Work_with_us Are you looking to work for Wikimedia? We have a lot of hiring coming up, and we really love talking to active community members about these roles. - Software Engineer - Editor Engagementhttp://hire.jobvite.com/Jobvite/Job.aspx?j=ovvXWfwD - Technical Writer - (Contract)http://hire.jobvite.com/Jobvite/Job.aspx?j=oGH5Wfw8 - Software Developer - Fundraisinghttp://hire.jobvite.com/Jobvite/Job.aspx?j=oF2EWfw1 - Software Engineer (Partners)http://hire.jobvite.com/Jobvite/Job.aspx?j=oX2hWfwW - Software Engineer (Apps)http://hire.jobvite.com/Jobvite/Job.aspx?j=oqU0Wfw0 - Software Developer General (Mobile)http://hire.jobvite.com/Jobvite/Job.aspx?j=o4cKWfwG - Software Engineer - Multimediahttp://hire.jobvite.com/Jobvite/Job.aspx?j=oj40Wfw3 - Software Engineer (Search)http://hire.jobvite.com/Jobvite/Job.aspx?j=ogk1Wfwh - Product Manager (Mobile)http://hire.jobvite.com/Jobvite/Job.aspx?j=oGWJWfw1 - Director of User Experiencehttp://hire.jobvite.com/Jobvite/Job.aspx?j=otv0WfwE - Visual Designer http://hire.jobvite.com/Jobvite/Job.aspx?j=oomJWfw9 - Operations Engineerhttp://hire.jobvite.com/Jobvite/Job.aspx?j=ocLCWfwf - Operations Engineer/Database Administratorhttp://hire.jobvite.com/Jobvite/Job.aspx?j=obMOWfwr - Site Reliability Engineerhttp://hire.jobvite.com/Jobvite/Job.aspx?j=o7k2Wfw9 - Tools Lab Operations Engineer (Contractor)http://hire.jobvite.com/Jobvite/Job.aspx?j=o7y3Wfwo Announcements - Yuvaraj Pandian re-joined the Mobile engineering teamhttps://www.mediawiki.org/wiki/Wikimedia_Mobile_engineeringas Software developer ( announcementhttp://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065636.html). He joined the newly created Mobile App team with Brion Vibber and Shankar Narayan. - Munagala Ramanath (Ram) joined the MediaWiki core team of the Platform engineeringhttps://www.mediawiki.org/wiki/Wikimedia_Platform_Engineeringgroup as Senior Software Engineer ( announcementhttp://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065698.html ). - Runa Bhattacharjee joined the Language Engineeringhttps://www.mediawiki.org/wiki/Wikimedia_Language_engineeringteam as Outreach and QA coordinator ( announcementhttp://lists.wikimedia.org/pipermail/wikitech-l/2013-January/066030.html ). Technical Operations *Production Site Switchoverhttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning * The Wikimedia Foundation switched over its primary data centerhttp://blog.wikimedia.org/2013/01/19/wikimedia-sites-move-to-primary-data-center-in-ashburn-virginia/from Tampa, Florida to Ashburn, Virginia on January 22. Given the scale and complexityhttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning/Stepsof the migration, we scheduled three 8-hour windows to perform the migration, but we were able to complete ithttp://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065892.htmlon the first attempt. Because the switchover involved, among
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
Yes, that is the prime reason we're still on 1.17 at work, it's the most recent version the FCKEditor extension works on. @Admins who use FCKEditor: please be reminded that be reminded, that FCKEditor has severe security issues. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries m...@tgries.de wrote: @Admins who use FCKEditor: please be reminded that be reminded, that FCKEditor has severe security issues. Yes, but as I mentioned until there is a suitable replacement, your choices are: run an insecure wiki, not use mediawiki. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 1.21wmf9 deployment blocker: bug 44748 (editing broken ku.wiktionary and sr.wikinews)
Hi folks,
We had to revert 1.21wmf9 on a few wikis due to bug 44748. Bug report:
https://bugzilla.wikimedia.org/44748
The problem is that, when 1.21wmf9 is enabled, editing is completely
broken on ku.wiktionary and sr.wikinews, among others.
Below is the stack trace. Any ideas?
Rob
2013-02-07 15:30:22 mw1061 kuwiktionary: [3f063856]
/w/index.php?title=d%C3%AAwaction=edit Exception from line 235 of
/usr/local/apache/common-local/php-1.21wmf9/languages/classes/LanguageKu.php:
Broken variant table:
#0
/usr/local/apache/common-local/php-1.21wmf9/languages/LanguageConverter.php(558):
KuConverter-translate('d??w', 'ku')
#1 /usr/local/apache/common-local/php-1.21wmf9/languages/Language.php(3660):
LanguageConverter-convertTitle(Object(Title))
#2 /usr/local/apache/common-local/php-1.21wmf9/includes/parser/Parser.php(439):
Language-convertTitle(Object(Title))
#3
/usr/local/apache/common-local/php-1.21wmf9/includes/cache/MessageCache.php(860):
Parser-parse('Anti-spam check...', Object(Title), Object(ParserOptions), true)
#4 /usr/local/apache/common-local/php-1.21wmf9/includes/Message.php(652):
MessageCache-parse('Anti-spam check...', NULL, true, true, Object(LanguageKu))
#5 /usr/local/apache/common-local/php-1.21wmf9/includes/Message.php(455):
Message-parseText('Anti-spam check...')
#6 /usr/local/apache/common-local/php-1.21wmf9/includes/Message.php(510):
Message-toString()
#7
/usr/local/apache/common-local/php-1.21wmf9/extensions/SimpleAntiSpam/SimpleAntiSpam.php(40):
Message-parse()
#8 [internal function]: efSimpleAntiSpamField(Object(EditPage),
Object(OutputPage))
#9 /usr/local/apache/common-local/php-1.21wmf9/includes/Hooks.php(256):
call_user_func_array('efSimpleAntiSpa...', Array)
#10
/usr/local/apache/common-local/php-1.21wmf9/includes/GlobalFunctions.php(3875):
Hooks::run('EditPage::showE...', Array)
#11 /usr/local/apache/common-local/php-1.21wmf9/includes/EditPage.php(2091):
wfRunHooks('EditPage::showE...', Array)
#12 /usr/local/apache/common-local/php-1.21wmf9/includes/EditPage.php(421):
EditPage-showEditForm()
#13
/usr/local/apache/common-local/php-1.21wmf9/includes/actions/EditAction.php(51):
EditPage-edit()
#14 /usr/local/apache/common-local/php-1.21wmf9/includes/Wiki.php(439):
EditAction-show()
#15 /usr/local/apache/common-local/php-1.21wmf9/includes/Wiki.php(305):
MediaWiki-performAction(Object(Article), Object(Title))
#16 /usr/local/apache/common-local/php-1.21wmf9/includes/Wiki.php(565):
MediaWiki-performRequest()
#17 /usr/local/apache/common-local/php-1.21wmf9/includes/Wiki.php(458):
MediaWiki-main()
#18 /usr/local/apache/common-local/php-1.21wmf9/index.php(59): MediaWiki-run()
#19 /usr/local/apache/common-local/live-1.5/index.php(3):
require('/usr/local/apac...')
#20 {main}
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering January 2013 report
On 07/02/13 20:57, Guillaume Paumier wrote: *Git conversion https://www.mediawiki.org/wiki/Git/Conversion* The ExtensionDistributorhttps://www.mediawiki.org/wiki/Extension:ExtensionDistributorwas rewritten in early January. While this was primarily done to support the data center migrationhttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning, this was the first time ExtensionDistributor had received any signification attention since the migration to Git. The new version now utilizes the Github API to generate extension snapshots. We hope that the new version will be more reliable for users. SVN-based extensions are no longer supported, but this is not expected to impact many users since these extensions are largely unmaintained (all popular and active extensions have long since moved to Gerrit). As always, these extensions will remain in SVN should anyone still want the code. Also worth mentioning, our SVN is now read-only. *Site performance https://www.mediawiki.org/wiki/Site_performance* A patch to allow moving the DB job queue to another cluster is under review. An experimental redis-based job queue patch also exists in gerrit. According to the link, it has already been merged. I guess that's change 39716, references to the changes should be prefered to ambiguous text like A patch. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering January 2013 report
On Thu, Feb 7, 2013 at 3:50 PM, Platonides platoni...@gmail.com wrote: On 07/02/13 20:57, Guillaume Paumier wrote: *Git conversion https://www.mediawiki.org/wiki/Git/Conversion* The ExtensionDistributorhttps://www.mediawiki.org/wiki/Extension:ExtensionDistributorwas rewritten in early January. While this was primarily done to support the data center migrationhttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning, this was the first time ExtensionDistributor had received any signification attention since the migration to Git. The new version now utilizes the Github API to generate extension snapshots. We hope that the new version will be more reliable for users. SVN-based extensions are no longer supported, but this is not expected to impact many users since these extensions are largely unmaintained (all popular and active extensions have long since moved to Gerrit). As always, these extensions will remain in SVN should anyone still want the code. Also worth mentioning, our SVN is now read-only. This actually happened on Feb 1st :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
Am 07.02.2013 21:46, schrieb OQ: On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries m...@tgries.de wrote: @Admins who use FCKEditor: please be reminded that be reminded, that FCKEditor has severe security issues. Yes, but as I mentioned until there is a suitable replacement, your choices are: run an insecure wiki, not use mediawiki. Use mediawiki, but do not use FCKEditor. see http://www.cvedetails.com/vulnerability-list/vendor_id-2724/Fckeditor.html Multiple directory traversal vulnerabilities in FCKeditor before 2.6.4.1 allow remote attackers to create executable files in arbitrary directories via directory traversal sequences in the input to unspecified connector modules, as exploited in the wild for remote code execution in July 2009, related to the file browser and the editor/filemanager/connectors/ directory. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.) The main requests from our corporate users are: 0. WYSIWIG editor. No surprise here. 1. A desire for a department to have their own space on the wiki. I'm not talking about access control, but (1) customized look feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax NamespaceName:SearchString. However, this is not a pleasant solution, because it's cumbersome to precede every article title with NamespaceName: when you create, link, and search. If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc. Some way to search within categories reliably would also be a huge win. Lucene provides incategory: but it misses all articles with transcluded category tags. 2. Hierarchy. Departments want not only their own space, they want subspaces beneath it. For example, Human Resources wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it goes since the main namespace is flat. I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it? 3. Tools for organizing large groups of articles. Categories and namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words Legal department (e.g., Legal department policies, Legal department meeting 2012-07-01, Legal department lunch, etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with Legal department... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once. 4. Integration with popular corporate tools like MS Office, MS Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next. 5. Corporate reorganizations and article titles. In any company, the names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name? Sure, you can move the article Finance department to Global Finance department and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called Finance department. You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killed noinclude tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes. Hope this was insightful/educational... DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
I don't mind these discussions, but can we please stop changing the subject, because it's changed three times and it makes it difficult to keep track of. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
- Original Message - From: Daniel Barrett d...@vistaprint.com 1. A desire for a department to have their own space on the wiki. I'm not talking about access control, but (1) customized look feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax NamespaceName:SearchString. However, this is not a pleasant solution, because it's cumbersome to precede every article title with NamespaceName: when you create, link, and search. If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc. Some way to search within categories reliably would also be a huge win. Lucene provides incategory: but it misses all articles with transcluded category tags. 2. Hierarchy. Departments want not only their own space, they want subspaces beneath it. For example, Human Resources wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it goes since the main namespace is flat. I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it? What you want, I think, is what Zope2 called acquisition. It's like OO subclass inheritance, but it's *geographic* depending on where you were in the tree; the old Mac Frontier system did something like it too. You want links to have a Search Path, that starts with whatever part/ subpart of the tree the current page is in, and then climbs the tree, ending in the unadorned Main namespace, whenever a user clicks them. That breaks the semantics of wikilinks some, but that's probably ok for your use. It *might* be generally useful; I'm trying to figure out if there are any obvious common use cases that it breaks, and how you tell where in the tree a page lives when it's created (and how you would show that to users). Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How can we help Corporations use MW? (Was Re: Comparisons to Confluence)
On 02/07/2013 08:17 AM, Mark A. Hershberger wrote: (Added MW-Enterprise mailing list) On 02/06/2013 10:00 PM, Tim Starling wrote: For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base. Totally agreed. I (along with a few other hardy volunteers) have been helping MW users at [[mw:Project:Support desk]] and it seems clear that the focus most developers have on the WMF use case has really made MW less usable for other people. One of my clients had an older (1.11) MediaWiki installation that they are using to share information with their distributors world-wide. Their first attempt to get the system to do what they wanted was a flop since the Java developer they had working on the system really didn't know that much about MW. I was able to get the system upgraded to 1.19 and adapt MW to their infrastructure using hooks, ResourceLoader, and pages they could update in the MediaWiki namespace. So, yes, I think MediaWiki has a lot to offer corporate users, but we haven't really made that clear or shown them how to do a lot of things they want to do. Tim has it right when he says MediaWiki needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. We've discussed this sort of thing over and over, but I think we're actually beginning to make some headway now thanks especially to work by Mariya Miteva. I'm really happy to read this! Mireya is doing this work because Sumana, myself and other WMF employees thought it would be good to have an internship (funded by the WMF as well) dedicated to sort out the panorama of MediaWiki vendors. https://www.mediawiki.org/wiki/Outreach_Program_for_Women I have proposed the use of MediaWiki Groups as a tool for 3rd party developers, consultants, MW users etc to get organized. Creating a group officially recognized by the Wikimedia movement is easy, there is almost no overhead and it would increase your chances of pushing your agenda. https://www.mediawiki.org/wiki/Groups If someone doesn't feel like being inside Wikimedia then s/he can jump to these groups as a Trojan. From a tactical point of view it seems reasonable to think that using the Wikipedia / Wikimedia inertia for your own good is more efficient than trying to jump away or swim against. Many 3rd parties consider MediaWiki because it is used by Wikipedia. The Wikimedia movement at large can also understand that a healthier MediaWiki 3rd party community helps having healthier software for Wikimedia projects. About the nice-looking website aimed at this user base, what is mediawiki.org missing? And, more broadly, what is this community missing? Tim made very good points in the paragraph above. The next step is to define the tasks / projects needed and find the resources for each. I'm happy helping in all these areas, but (needless to say) they must be driven by 3rd parties. Mariya will be working full time on MediaWiki vendors 7-8 weeks more. It would be great to use as much of her time and energies to build a minimum level of concretion and coordination. So far many of you have done a great job helping her to help you. :) -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki API at Codecademy?
Long story short: the MediaWiki API could be included at http://www.codecademy.com/tracks/apis if someone wants to do the work. Codecademy is happy to have us there. I think it is a good idea, in need of someone willing to drive this: - It is a good excuse to improve our API documentation at mediawiki.org. - Codecademy is a good place to reach to more developers. - Maybe it is a good chance for someone to take this as a paid job? The Wikimedia movement wants to spread the 1,3T of content we have, and get more free content from as many channels as possible. Our API plays a big role on this. Therefore, I *personally* believe that a project to update the API documentation at mediawiki.org and have corresponding exercises at Codecademy has a chance to receive a grant if the proposal and the candidate(s) are solid. Interested? Let me help you. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
I will be happy to part-take in this, as I do have some experience with the API :) I am heading the API v2 project, and this would be a natural extension of that. * RFC http://www.mediawiki.org/wiki/Requests_for_comment/API_Future * Action/Parameter Cleanuphttp://www.mediawiki.org/wiki/Requests_for_comment/API_Future/Naming_Cleanup On Thu, Feb 7, 2013 at 6:12 PM, Quim Gil q...@wikimedia.org wrote: Long story short: the MediaWiki API could be included at http://www.codecademy.com/**tracks/apishttp://www.codecademy.com/tracks/apis if someone wants to do the work. Codecademy is happy to have us there. I think it is a good idea, in need of someone willing to drive this: - It is a good excuse to improve our API documentation at mediawiki.org. - Codecademy is a good place to reach to more developers. - Maybe it is a good chance for someone to take this as a paid job? The Wikimedia movement wants to spread the 1,3T of content we have, and get more free content from as many channels as possible. Our API plays a big role on this. Therefore, I *personally* believe that a project to update the API documentation at mediawiki.org and have corresponding exercises at Codecademy has a chance to receive a grant if the proposal and the candidate(s) are solid. Interested? Let me help you. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] NullLockManager and the math extension
On 02/06/2013 08:09 PM, Aaron Schulz wrote: nullLockManager is defined in Setup.php.The code: LockManagerGroup::singleton()-get( 'nullLockManager' ); ... works fine in eval.php and is used in production. However, $wgLockManagers is redefined in parserTest.inc . It looks like it's basically the same as in a654a6e79adc8f4730bb69f79e0b6a960d7d3cbe (MW core) . Tim Starling added an explicit set to $wgLockManagers with only fsLockManager. It doesn't look like this was to block use of the null lock manager, but rather to specify the lockDirectory on the fs one. Does it make sense to add null lock manager to parserTest.inc there as well? The reason I'm asking is https://bugzilla.wikimedia.org/show_bug.cgi?id=43222 . https://gerrit.wikimedia.org/r/#/c/30177 changed the lock manager from null to fs. But that wasn't part of the intent of the change. It was just to work around the test issue. If I can change parserTest.inc, I can put the default back to null. Note that WMF uses: 'wmgMathFileBackend' = array( 'default' = 'global-multiwrite' ), in production. Thanks, Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
