Re: [Wikitech-l] Meetings vs mailing list (Re: Should MediaWiki CSS prefer non-free fonts?)
On Sun, Feb 16, 2014 at 10:04 AM, Jon Robson wrote: Brad since you work for the for the foundation and seem to have a lot of expertise in this area and seem to have been one of the more vocal supporters of free fonts have you reached out to your work colleagues over video conferencing or similar to understand the problems being hit and helped them work through them? Email doesn't seem to have been an effective method of communication in this situation as you have pointed out. Maybe you can help with documenting these issues and helping people like yourself understand the problems and why this change was reverted? It always is a good idea to read IRC and pick up ideas there — especially if a channel isn't logged! If an idea is fruitful, you just get it actioned off-irc (as a bug report, or as an addition to documentation). For decision-making IRC is just more interactive and more ideas get conveyed and analyzed with less effort. E-mail and formal meetings are in my view harder due to difficulty in conveying ideas or simply participating where I come up with a small idea and want to simply know what others think of it without putting effort into writing a verbose email. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Non-Violent Communication
Derric Atzrott writes: Have any of you ever heard of Non-Violent Communication (NVC). NVC is amazing and I very much encourage anyone to take it up. It goes way beyond a method of thinking, it is a spiritual path. Like other spiritual paths that means it may work if you practise it yourself. This is a pretty violent name for such a relaxed concept. Related essays: - https://meta.wikimedia.org/wiki/Excessive_growth - https://meta.wikimedia.org/wiki/Catalytic ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Meetings vs mailing list (Re: Should MediaWiki CSS prefer non-free fonts?)
Le 19/02/2014 09:34, Gryllida a écrit : For decision-making IRC is just more interactive and more ideas get conveyed and analyzed with less effort. Since IRC is more or less real time, that dismiss feedback from people not in the room (ie sleeping because of different timezone, not paying attention etc). So yeah if you want quick feedback for something small, IRC is nice. Else mailing list must be used to reach a wider audience. The meetings are nice when you want to start the process or to close it. They also get you to the point faster than day long mailing lists debates. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
Le 18/02/2014 18:48, Trevor Parscal a écrit : PHP 5.4 added a few important features[1], namely traits, shorthand array syntax, and function array dereferencing. I've heard that 5.3 is nearing end of life. I propose we drop support for PHP 5.3 soon, if possible. Hello, One of the requirement we have enforced is that MediaWiki must be installable on Debian stable. The current stable version ships 5.4 now so that is a fulfilled requirement. Ubuntu Precise LTS has php 5.3. We have a MediaWiki LTS as well, so people can use that instead of the latest version. We want MediaWiki to be installable on as many hosting services as possible. I do not have any metric, but hopefully most services come with php 5.4 nowadays. As for Ubuntu, if someone hosting service still use php 5.3, they can use the MediaWiki LTS version. A requirement Wikimedia has nowadays is that the code MUST be supported with HipHop Virtual Machine. As an example, I do not think it implements the SPL classes. So that needs to be carefully checked. Another very important point is whether we want to actually use 5.4 new features. Reviewing the list of 5.3 new features: * namespaces : we did not see a good use case for them * Late Static Bindings : consensus that it is merely a workaround for badly designed code * jump labels : dinosaur will eat you http://www.xkcd.com/292/ ( I like goto myself and yeah they have valid use cases ). * Closures (lambda/anonymous) : that made the code easier to follow when using callbacks since the callbacks code is next to the caller. * __callStatic() __invoke() : never seen that used in our code * Constants declared with 'const' : we use define() * short ternary operator '?:' : haven't seen it * nested exceptions : maybe we end up using them somehow. Not sure. * circular refs garbage collection : it is enabled by default Of course you have some new functions and build-in classes. But beside that, we barely use any 5.3 new features. I do not think this thread is a good opportunity to bikeshed/talk/reach consensus about 5.4 features. That is eventually a can of worm that would need to be opened and some consensus reached for each features. The real blocker is hhvm matching 5.4 features. List of new features: http://php.net/manual/en/migration53.new-features.php http://php.net/manual/en/migration54.new-features.php -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Meetings vs mailing list (Re: Should MediaWiki CSS prefer non-free fonts?)
From: Antoine Musso Date: Wed, 19 Feb 2014 11:28:33 +0100 Le 19/02/2014 09:34, Gryllida a écrit : For decision-making IRC is just more interactive and more ideas get conveyed and analyzed with less effort. [...] The meetings are nice when you want to start the process or to close it. They also get you to the point faster than day long mailing lists debates. Not sure what you mean. There usually is no need to debate; you can just come to irc and reach understanding /easier/. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Syrian authorities censored Wikipedia access
An analysis of Syrian internet censorship shows Wikimedia sites among the top 10 censored domains. See Table 5 on page 6. The data they're analyzing is the filtering proxy logs from October 2011, so a lot's changed in our systems since then; for instance, the section on page 7 regarding HTTPS traffic might be completely inapplicable to us now. But I figured it was worth passing around. Paper: http://arxiv.org/pdf/1402.3401.pdf , found via http://boingboing.net/2014/02/18/detailed-analysis-of-syrias.html . Censorship in the Wild: Analyzing Web Filtering in Syria by Abdelberi Chaabane, Mathieu Cunche, Terence Chen, Arik Friedman, Emiliano De Cristofaro, and Mohammed-Ali Kafaar. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Syrian authorities censored Wikipedia access
On 2/19/14, Sumana Harihareswara suma...@wikimedia.org wrote: An analysis of Syrian internet censorship shows Wikimedia sites among the top 10 censored domains. See Table 5 on page 6. The data they're analyzing is the filtering proxy logs from October 2011, so a lot's changed in our systems since then; for instance, the section on page 7 regarding HTTPS traffic might be completely inapplicable to us now. But I figured it was worth passing around. Paper: http://arxiv.org/pdf/1402.3401.pdf , found via http://boingboing.net/2014/02/18/detailed-analysis-of-syrias.html . Censorship in the Wild: Analyzing Web Filtering in Syria by Abdelberi Chaabane, Mathieu Cunche, Terence Chen, Arik Friedman, Emiliano De Cristofaro, and Mohammed-Ali Kafaar. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I only skimmed the paper, but interestingly all the charts mention wikimedia.org being censored, not wikipedia.org. I imagine that means they are censoring pictures/videos rather than actual articles (presumably.). --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using Special page transclusion as a rudimentary API in Scribunto/Lua modules
On Wed, Feb 19, 2014 at 2:23 AM, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Feb 19, 2014 at 1:26 AM, MZMcBride z...@mzmcbride.com wrote: There are likely others. What can be done to address this issue? Only way I can think of is to improve the Lua - PHP API so that users can make the queries directly. Patches welcome. Keep in mind that we don't want to be fetching huge pagelists many times per page, so most such functions should probably be marked expensive, should have a reasonable maximum limit on results per call, and the database queries must be well-indexed. Relevant bugs include: * https://bugzilla.wikimedia.org/show_bug.cgi?id=48175 * https://bugzilla.wikimedia.org/show_bug.cgi?id=48174 * https://bugzilla.wikimedia.org/show_bug.cgi?id=47137 -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
On Wed, Feb 19, 2014 at 5:49 AM, Antoine Musso hashar+...@free.fr wrote: * short ternary operator '?:' : haven't seen it It's being used in a few places; probably a variation that was equivalent to isset( $foo ) ? $foo : $bar would see more use though. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Thoughts on hiding text from the internal search
I can make a better case for hiding things from internal search then I did on the bug. I'll send it here and copy it to the mailing list: The biggest case I can think of for excluding text from search is the license information on commons. Please take that as an example. Maybe it is the only example I think it is pretty important. 1. The license information doesn't add a whole lot to the result. Try searching commons with Cirrus for distribute, transmit, or following and you'll very quickly start to see the text of the CC license. And the searches find 14 million results. Heaven forbid you want to find distributed transmits or something. You'll almost exclusively get the license highlighted and you'll still find 14 million results. This isn't _horrible_ because the top results all have distribute or transmit in the title but it isn't great. 2. Knock on effect from #2: because relevance is calculated based on the inverse of the number of documents that contain the word the then every term in the CC license is worth less then words not in the license. I can't point to any example of why that is bad but I feel it in my bones. Feel free to ignore this. I'm probably paranoid. 3. Entirely self serving: given #1, the contents of the license take up an awful lot of space for very little benefit. If I had more space I could make Cirrus a beta on more wikis. It is kind of a lame reason and I'm attacking the space issue from other angles so maybe it'll be moot long before we get this deployed and convince the community that it is worth doing. 4. Really really self serving: if .nosearch is the right solution and is useful then it is super duper easy to implement. Like one line of code, a few tests, and bam. Its already done, just waiting to be rebased and merged. It was so easy it would have taken longer to estimate the effort then to propose an implementation. I really wouldn't be surprised if someone couldn't come up with great reason why #1 is silly and we just shouldn't do it. The big problem with the nosearch class implementation is that it'd be pretty simple to abuse and hard to catch the abuse because the text is still on the page. One of the nice things about the solution is you could use a web browser's debugger to highlight all the text excluded from search by writing a simple CSS class. I think that is all I have on the subject, Nik/manybubbles On Wed, Feb 19, 2014 at 1:29 AM, Chad innocentkil...@gmail.com wrote: On Tue, Feb 18, 2014 at 9:50 PM, MZMcBride z...@mzmcbride.com wrote: Chad wrote: I'm curious how people would go about hiding text from the internal MediaWiki search engine (not external robots). Right now I'm thinking of doing a rather naïve .nosearch class that would be stripped before indexing. I can see potentials for abuse though. Does anyone have any bright ideas? It's difficult to offer advice without knowing why you're trying to do what it is you're trying to do. You've described a potential solution, but I'm not sure what problem you're trying to solve. Are there some example use-cases or perhaps there's a relevant bug in Bugzilla? Ah, here's the bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=60484 -Chad ___ 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] Thoughts on hiding text from the internal search
On Wed, Feb 19, 2014 at 12:14 PM, Nikolas Everett never...@wikimedia.org wrote: The big problem with the nosearch class implementation is that it'd be pretty simple to abuse and hard to catch the abuse because the text is still on the page. One of the nice things about the solution is you could use a web browser's debugger to highlight all the text excluded from search by writing a simple CSS class. What if the abuse is inside of a hidden element? http://jsfiddle.net/WQ6K2/ Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Thoughts on hiding text from the internal search
On Wed, Feb 19, 2014 at 12:17 PM, Helder . helder.w...@gmail.com wrote: On Wed, Feb 19, 2014 at 12:14 PM, Nikolas Everett never...@wikimedia.org wrote: The big problem with the nosearch class implementation is that it'd be pretty simple to abuse and hard to catch the abuse because the text is still on the page. One of the nice things about the solution is you could use a web browser's debugger to highlight all the text excluded from search by writing a simple CSS class. What if the abuse is inside of a hidden element? http://jsfiddle.net/WQ6K2/ Helder Yeah, nowhere near perfect. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Thoughts on hiding text from the internal search
Don't suppose there'd be any way to do both things - an index to search normally, and one to search full of everything if someone's searching for hidden stuff. -L On 19/02/14 17:39, Nikolas Everett wrote: On Wed, Feb 19, 2014 at 12:17 PM, Helder . helder.w...@gmail.com wrote: On Wed, Feb 19, 2014 at 12:14 PM, Nikolas Everett never...@wikimedia.org wrote: The big problem with the nosearch class implementation is that it'd be pretty simple to abuse and hard to catch the abuse because the text is still on the page. One of the nice things about the solution is you could use a web browser's debugger to highlight all the text excluded from search by writing a simple CSS class. What if the abuse is inside of a hidden element? http://jsfiddle.net/WQ6K2/ Helder Yeah, nowhere near perfect. ___ 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] Drop support for PHP 5.3
On Feb 18, 2014, at 10:10 AM, Faidon Liambotis fai...@wikimedia.org wrote: However, last I heard, platform engineering is focusing on HHVM now instead, so I'm not sure if it actually makes sense to spend resources to move to PHP 5.4 right now. Just as a data point, Wikia already runs php 5.4 in production. If I remember correctly there were some things that had to be fixed around the (deprecated in 5.3) call time pass by reference “feature” being removed, but it wasn’t much effort at all. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Thoughts on hiding text from the internal search
Or use structured search instead of hiding things, so that you can search (say) just the titles of images on commons without corrupting the title index with license text. --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The Zürich Hackathon and you
On 02/08/2014 06:25 AM, Mark A. Hershberger wrote: On 02/06/2014 07:17 PM, Quim Gil wrote: Hi, the registration to the Zürich Hackathon will open very soon. \o/ I'm looking forward to this as I plan on bringing along some newbies. \o/ \o/ \o/ * defining the schedule How much of the previous years schedules can be reused? How much do you want to reuse? :) We are still in need of 2-3 volunteers to drive the schedule. I don't think it is much work and, as said, I can help. Mark, would you like to volunteer providing the MediaWiki-not-Wikimedia perspective? Anybody would like to provide the Wikimedia perspective(s)? What about other perspectives? Come on, it is a good chance to step in and do some good. -- 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] The Zürich Hackathon and you
What do you need schedulewise? On Wed, Feb 19, 2014 at 8:09 PM, Quim Gil q...@wikimedia.org wrote: On 02/08/2014 06:25 AM, Mark A. Hershberger wrote: On 02/06/2014 07:17 PM, Quim Gil wrote: Hi, the registration to the Zürich Hackathon will open very soon. \o/ I'm looking forward to this as I plan on bringing along some newbies. \o/ \o/ \o/ * defining the schedule How much of the previous years schedules can be reused? How much do you want to reuse? :) We are still in need of 2-3 volunteers to drive the schedule. I don't think it is much work and, as said, I can help. Mark, would you like to volunteer providing the MediaWiki-not-Wikimedia perspective? Anybody would like to provide the Wikimedia perspective(s)? What about other perspectives? Come on, it is a good chance to step in and do some good. -- 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 -- Maybe you knew early on that your track went from point A to B, but unlike you I wasn't given a map at birth! Alyssa, Chasing Amy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The Zürich Hackathon and you
On 02/19/2014 11:11 AM, Finne Boonen wrote: What do you need schedulewise? We need someone driving the process of defining a schedule based on the characteristics of the venue, https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Topics , and whatever other factors the Hackathon participants want to consider (pre-scheduled vs open slots, all-hands vs breakouts, lecture vs BoF vs workshop...) It's not rocket science, but someone must be in charge. -- 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] The Zürich Hackathon and you
I am willing to volunteer depending on the tasks. Time is not an issue for me. Andrew On 2/19/14, 1:22 PM, Quim Gil q...@wikimedia.org wrote: On 02/19/2014 11:11 AM, Finne Boonen wrote: What do you need schedulewise? We need someone driving the process of defining a schedule based on the characteristics of the venue, https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Topics , and whatever other factors the Hackathon participants want to consider (pre-scheduled vs open slots, all-hands vs breakouts, lecture vs BoF vs workshop...) It's not rocket science, but someone must be in charge. -- 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Thoughts on hiding text from the internal search
On Wed, Feb 19, 2014 at 11:02 AM, C. Scott Ananian canan...@wikimedia.orgwrote: Or use structured search instead of hiding things, so that you can search (say) just the titles of images on commons without corrupting the title index with license text. We don't lump the title with the text. The problem is when you've got a wiki where there's a whole lot of the same text so it becomes harder to search for things that happen to also be in that repeated text. Two good examples so far are welcome-style templates on Talk namespaces and License templates on files. Another way of summarizing this is: we want to index all of the page text, except when we don't. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The Zürich Hackathon and you
On 02/19/2014 11:25 AM, Andrew DeSantis wrote: I am willing to volunteer depending on the tasks. Time is not an issue for me. Thank you Andrew, but I don't think this is a good task for a newcomer. It is a good task for regular contributors that haven't been previously involved in the organizations of events, though. On 2/19/14, 1:22 PM, Quim Gil q...@wikimedia.org wrote: On 02/19/2014 11:11 AM, Finne Boonen wrote: What do you need schedulewise? We need someone driving the process of defining a schedule based on the characteristics of the venue, https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Topics , and whatever other factors the Hackathon participants want to consider (pre-scheduled vs open slots, all-hands vs breakouts, lecture vs BoF vs workshop...) It's not rocket science, but someone must be in charge. -- 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] RFC review this Friday: HTML templating + Service Oriented Architecture
This week, we're mostly discussing the HTML templating and SOA RFCs - https://www.mediawiki.org/wiki/Architecture_Summit_2014/HTML_templating and https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces have more information. Gabriel Wicke will be asking for some decisions on both. :) https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21says that we'll also talk briefly about guideline documents. You can add one more RFC to the agenda if you need a decision on something. Brion will be there but not Tim. Discussion in #wikimedia-office at 17:00 UTC on Friday the 21st: http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+reviewiso=20140221T09p1=224ah=1 Pacific: 9am US Eastern: noon Berlin, Germany: 18:00 India: 22:30 Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
Regarding PHP 5.3 support, I put together a quick report in WikiApiary showing the versions of PHP in use across wikis. https://wikiapiary.com/wiki/PHP_Versions In short, 5.3 is the most common PHP version used by a large, large majority. Three things to footnote in this data (and you could run additional queries to get the real data for these). 1. WMF itself runs PHP 5.3, so that explodes the user count a lot. If you excluded WMF (based on an assumption that WMF controls it so thus could move to newer version easily) it lowers the active users on 5.3 dramatically. 2. A large percentage of the 5.3 install base is there because that is what Ubuntu is distributing (my farm is on 5.3 for this reason). If there was an easy PPA solution to move from 5.3 to 5.4 for Ubuntu 12.04 that would also lessen the dependency on 5.3. 3. If you queried by Netblock you could identify how many of these 5.3 users are on Bluehost, Dreamhost or other system where they have no ability to upgrade, the hosted would have to do that. All data (except time series edit data) for WikiApiary is stored as semantic properties, so all of these things are available for #ask queries. -- Jamie Thingelstad ja...@thingelstad.com On Wed, Feb 19, 2014, at 11:01 AM, Owen Davis wrote: On Feb 18, 2014, at 10:10 AM, Faidon Liambotis fai...@wikimedia.org wrote: However, last I heard, platform engineering is focusing on HHVM now instead, so I'm not sure if it actually makes sense to spend resources to move to PHP 5.4 right now. Just as a data point, Wikia already runs php 5.4 in production. If I remember correctly there were some things that had to be fixed around the (deprecated in 5.3) call time pass by reference “feature” being removed, but it wasn’t much effort at all. ___ 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] Proof of concept implementation for Structured logging RFC
On Wed, Feb 12, 2014 at 11:20 AM, Bryan Davis bd...@wikimedia.org wrote: Yesterday I opened Gerrit change 112699 [0] with a proof of concept implementation for the Structured logging RFC [1] that leverages PSR-3 and Monolog. I'm sure it's not ready to merge yet but hopefully it will get some attention from interested parties to move this discussion forward. After a week the criticism of my patch seems to boil down to complaints about usage of Monolog, both packaging and MW facing interface. Does anyone have a constructive suggestion on how to better incorporate a third party library dependency into core? I really don't want the answer to be that's too hard, let's roll our own logger. It would be pretty easy to satisfy the current logging needs of the wiki[pm]edia production cluster by going down that route but that doesn't really help others get structured logging without replicating the same infrastructure (and requirements). I agree that what I'm doing here is not elegant but I think it could be functional in the near term. in the long view the third party library issue needs a better solution. Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
