Re: [Wikitech-l] From Node.js to Go
I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options. Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch? On Thu, Jan 29, 2015 at 9:18 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: Language fragmentation is always fun, but, as with any new one, my concerns lie in the environment - is there enough tools to make the advertised benefits worth it, does it have a decent IDE with the smart code completion, refactoring, and a good debugger? Does it have a packaging/dependency system? How extensive is the standard library, and user contributed packages. How well does it play with the code written in other languages? The list could go on. In short - we can always try new things as a small service )) And yes, Rust also sounds interesting. On Jan 29, 2015 7:22 PM, Ori Livneh o...@wikimedia.org wrote: (Sorry, this was meant for wikitech-l.) On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh o...@wikimedia.org wrote: We should do the same, IMO. http://bowery.io/posts/Nodejs-to-Golang-Bowery/ ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Urlencoding strip markers
On Fri, Jan 30, 2015 at 12:11 PM, Jackmcbarn jackmcb...@gmail.com wrote: On Fri, Jan 30, 2015 at 2:02 PM, Brion Vibber bvib...@wikimedia.org wrote: On Thu, Jan 29, 2015 at 5:38 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Thu, Jan 29, 2015 at 2:47 PM, Arlo Breault abrea...@wikimedia.org wrote: https://gerrit.wikimedia.org/r/#/c/181519/ To clarify, the possible solutions seem to be: 1. Unstrip the marker and then encode the content. This is a security hole (T73167) I'd be inclined to unstrip the marker *and squash HTML to plaintext*, then encode the plaintext... I don't see how that addresses the security issue. Rollback tokens in the Special:Contributions HTML would then not be available in the squashed text that got encoded. Thus it could not be extracted and used in the timing attack. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] From Node.js to Go
On Fri, Jan 30, 2015 at 11:23 AM, Brion Vibber bvib...@wikimedia.org wrote: Hmm, IIRC using Hack means you can't use xdebug with Zend PHP ... is debugging with HHVM in PhpStorm possible yet/soon? (I just figured out the debugger setup with Zend PHP and MediaWiki-Vagrant, and it's wonderful to have a debugger in PHP :D ) -- brion The xdebug remote debugging was unstable in 3.3, as of 3.4 it has now considered stable. I have not actually tried it myself though. It looks like the hhvm version we are packaging is 3.3.1, so in vagrant it will be a bit unstable atm. Erk B. On Fri, Jan 30, 2015 at 11:14 AM, Chad innocentkil...@gmail.com wrote: On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis bd...@wikimedia.org wrote: On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdoug...@wikimedia.org wrote: I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options. Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch? I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think. Yeah, I'd -2 anything that required Hack in core. However if an extension wants to experiment they probably could. I was already thinking of trying some Hack in something WMF-specific like a Wikimedia* extension. -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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting debug logging to PSR-3
This is great bryan, thanks for moving this all forward. One exciting part of this logging update is that the log methods also take a context array which (i believe) is imported to kibana and searchable via elasticsearch. Has any effort been put into best practices around what should be in these context arrays? In my experiences at a $job-1 being able to find related logs via these context values was incredibly useful. We implemented both a global logging context which was used for all logs of the same request including a hash that uniquely identifies the request, the username if logged in, and the route(we don't have a direct equiv to route, Title in some cases). Area specific debugging would add their own info. For example if failing to connect to a remote server it would be included in the logging context so we could easily find all errors connecting to the same machine. Erik B. On Fri, Jan 30, 2015 at 11:07 AM, Brion Vibber bvib...@wikimedia.org wrote: Huge thanks for this -- logging with wfDebug() and friends has always been a little primitive, and this is both more flexible and lets us remove some of our weird custom code. :) -- brion On Thu, Jan 29, 2015 at 11:45 PM, Bryan Davis bd...@wikimedia.org wrote: PSR-3 logging has been fully supported in MediaWiki since1.25wmf5. We've been making various tuning improvements since then including a recent deprecation of the initial MWLogger wrapper class in favor of direct usage of Psr\Log\LoggerInterface by wfDebugLog() and other internal wrapper methods [2]. The next big step in introducing structured logging to MediaWiki is to begin to replace calls to wfDebugLog() (and dear god wfDebug()) with direct usage of Psr\Log\LoggerInterface instances. Kunal and I have a couple starter patches that show this in gerrit [3]. In both conversions we have chosen to implement Psr\Log\LoggerAwareInterface in the effected classes to allow setter based injection of a LoggerInterface. The log channel names were also chosen to match the previous wfDebugLog logGroup values. When you use a PSR-3 logger you need to choose a severity for each log message. PSR-3 has quite a few possible levels, but I'd like to propose that we really only need 4 to start with in MediaWiki: * debug: Useful for ummm debugging. :) These are messages that are useful for local development and are generally too spammy to output on a production wiki. This would typically include anything currently being logged via wfDebug. * info: Valuable state change information. This level is a great place to record information that would be useful in a production environment when tracing the path of a request that eventually had an error. * warning: A soft error condition such as a recoverable error or another condition that typically should not be seen but isn't halting for the operation in process * error: A hard error such as a caught exception with no recovery path. The notice, critical, alert and emergency log levels seem unnecessary to me, but I'm willing to hear arguments about where they are super duper useful for some log event state that I haven't thought of yet. When thinking about Wikimedia cluster logging, events emitted at warning and error levels should be things that you want deployers and operations staff to see in the Logstash fatalmonitor view and recorded to other durable logging stores. Events at info level may or may not be captured similar to how we currently enable some but not all wfDebugLog channels. Events at debug level will probably only be captured in beta labs and similar low volume debugging environments. The wfDebug* methods are not being deprecated officially yet but it would be great if people started treating them like they were deprecated when writing new classes. It would be even more awesome if more folks started making small cleanup patches to convert existing classes to the new style of logging. Tagging gerrit reviews for these patches with PSR-3 as either a submitter or a reviewer would also be appreciated. [0]: https://gerrit.wikimedia.org/r/#/c/119940/ [1]: https://gerrit.wikimedia.org/r/#/c/185210/ [2]: https://gerrit.wikimedia.org/r/#/c/184830/ [3]: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:master+topic:PSR-3,n,z 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___
Re: [Wikitech-l] Converting debug logging to PSR-3
On Fri, Jan 30, 2015 at 12:00 PM, Gergo Tisza gti...@wikimedia.org wrote: On Thu, Jan 29, 2015 at 11:45 PM, Bryan Davis bd...@wikimedia.org wrote: The wfDebug* methods are not being deprecated officially yet but it would be great if people started treating them like they were deprecated when writing new classes. So why not actually deprecate them? As Bryan said I think we should, for new classes in core. They're unlikely to need backporting. https://www.mediawiki.org/wiki/Manual:How_to_debug#Logging seems to be the place to deprecate, plus the various $wg pages. For extensions, our compatibility guidelines [1] say both * trunk extensions only have to support current trunk MediaWiki * and don't break support for old MediaWiki versions unless the compatibility code is causing actual quantifiable problems. So an extension like Flow which depends on fixes to core in 1.25 might as well switch. Whatever extension developers decide, the Extension: page must express the reality of the MW version(s) it requires to work. For sample code, it's tricky. Should mw.org have code that shows developers how to write extensions that run on latest git or on Download MediaWiki 1.24.1, or both? (And even for the legacy LTS releases 1.23.8 and 1.19.23.) [1] https://www.mediawiki.org/wiki/Backward_compatibility#Trunk_extensions.27_compatibility_with_old_MediaWiki_versions [2] https://www.mediawiki.org/wiki/Extension_registration -- =S Page WMF Tech writer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting debug logging to PSR-3
On Fri, Jan 30, 2015 at 11:44 AM, Erik Bernhardson ebernhard...@wikimedia.org wrote: This is great bryan, thanks for moving this all forward. One exciting part of this logging update is that the log methods also take a context array which (i believe) is imported to kibana and searchable via elasticsearch. Has any effort been put into best practices around what should be in these context arrays? In my experiences at a $job-1 being able to find related logs via these context values was incredibly useful. We implemented both a global logging context which was used for all logs of the same request including a hash that uniquely identifies the request, the username if logged in, and the route(we don't have a direct equiv to route, Title in some cases). Area specific debugging would add their own info. For example if failing to connect to a remote server it would be included in the logging context so we could easily find all errors connecting to the same machine. The context data provided with a log message will indeed be passed on to Logstash on the WMF cluster and eventually end up as viewable/searchable in the Kibana frontend. We are using Monolog as the PSR-3 implementation library on the cluster [0]. In the current configuration we are adding several things to all log messages using Monolog's Processor classes: * host = wfHostname() * wiki = wfWikiID() * process_id = getmypid() * uid = random 7 digit hex integer that correlates all log events for a given request * url = $_SERVER['REQUEST_URI'] * ip = $_SERVER['REMOTE_ADDR'] * http_method' = $_SERVER['REQUEST_METHOD'] * server = $_SERVER['SERVER_NAME'] * referrer = $_SERVER['HTTP_REFERER'] It would be great to come up with standard names for other bits of information that might commonly be attached to a log message. 'exception' is a pretty easy one to pick for adding an Exception class to a log event. Monolog will automagically expand any Exception in the log event's context to a nice structure similar to our exception-json log event stream. 'method' and 'class' might be reasonable standard keys to use as well. [0]: http://noc.wikimedia.org/conf/highlight.php?file=logging.php 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
Re: [Wikitech-l] From Node.js to Go
Hi! The last time I saw someone asking if it was faster on #hhvm the answer was not yet. Whether strong typing is a pro or a con of Hack vs PHP seems like a religious debate that I'll try to stay out of until the issue is forced. The bits most likely to be of interest in the short term are the `async` and `await` keywords [0] and possibly the Continuation class [1] which makes creating generators easier than the PHP Iterator interface. PHP 5.5+ has actual generators: http://php.net/manual/en/language.generators.overview.php The typed code would not be faster by itself unless some optimizations actually using type information would be done (not sure if HHVM has such optimizer), but that would require writing actually typed code which would not be PHP of course. And this probably will be useful only for scalar types, since there's not much happening at runtime with non-scalar typing that can be eliminated by stronger types (for scalar types, conversions and type branches in operators, parameter passing, etc. can be eliminated). -- Stas Malyshev smalys...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Urlencoding strip markers
On Thu, Jan 29, 2015 at 5:38 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: 4. Remove the marker. This loses whatever is inside the marker. 5. Just output an error, to make it obvious something stupid is going on. Failing loud and early is generally a good idea, but if we don't want that, maybe replace the marker with STRIP-MARKER-WAS-REMOVED-SEE-BUG-12345? That at least gives a fighting chance to editors trying to debug why the template does not work as expected. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Urlencoding strip markers
On Thu, Jan 29, 2015 at 5:38 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Thu, Jan 29, 2015 at 2:47 PM, Arlo Breault abrea...@wikimedia.org wrote: https://gerrit.wikimedia.org/r/#/c/181519/ To clarify, the possible solutions seem to be: 1. Unstrip the marker and then encode the content. This is a security hole (T73167) I'd be inclined to unstrip the marker *and squash HTML to plaintext*, then encode the plaintext... -- brion 2. Encode the marker. This results in strip markers in the output. 3. Ignore the marker. This leaves non-encoded content in the middle of what is supposed to be encoded content. 4. Remove the marker. This loses whatever is inside the marker. 5. Just output an error, to make it obvious something stupid is going on. There's no good option, so which of 2, 3, 4, and 5 is least bad? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ 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] [WikimediaMobile] Florian for +2 on MobileFrontend?
CC'ing wikitech-l@ to broaden the reach of this
--tomasz
On Fri, Jan 30, 2015 at 10:32 AM, Jon Robson jrob...@wikimedia.org wrote:
I've proposed that Florian gets +2 on the MobileFrontend repository.
Florian has been an extremely active MobileFrontend developer (he is
our 5th most active contributor).
It would be great to have him helping out with merging patches. He
also is based in Europe so it would strengthen our ability to get
regressions fixed on different timezones quicker!
You can support this by voting using the {{support}} template on:
https://www.mediawiki.org/wiki/Gerrit/Project_ownership#.2B2_for_Florian_Schmidt_on_mediawiki.2Fextensions.2FMobileFrontend
Please show your {{support}} on the wiki page to make this happen!
(In the words of Spiderman with great power comes great reponsibility)
___
Mobile-l mailing list
mobil...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Add members to extension owners
Thanks to whoever helped out! On 30 January 2015 at 11:18, Stephan Gambke s7ep...@gmail.com wrote: What is the process to add people as owners of an extension? What is described on mw.org [0] does not work. Contrary to what is written there I can not add group members myself to a group that I am in. And a request I added there is open now for more than three months. So, what do I have to do to give other people access to extensions? Are there any plans to streamline that process? Stephan http://www.mediawiki.org/wiki/Gerrit/Project_ownership#To_make_a_new_Project_Owner ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting debug logging to PSR-3
Huge thanks for this -- logging with wfDebug() and friends has always been a little primitive, and this is both more flexible and lets us remove some of our weird custom code. :) -- brion On Thu, Jan 29, 2015 at 11:45 PM, Bryan Davis bd...@wikimedia.org wrote: PSR-3 logging has been fully supported in MediaWiki since1.25wmf5. We've been making various tuning improvements since then including a recent deprecation of the initial MWLogger wrapper class in favor of direct usage of Psr\Log\LoggerInterface by wfDebugLog() and other internal wrapper methods [2]. The next big step in introducing structured logging to MediaWiki is to begin to replace calls to wfDebugLog() (and dear god wfDebug()) with direct usage of Psr\Log\LoggerInterface instances. Kunal and I have a couple starter patches that show this in gerrit [3]. In both conversions we have chosen to implement Psr\Log\LoggerAwareInterface in the effected classes to allow setter based injection of a LoggerInterface. The log channel names were also chosen to match the previous wfDebugLog logGroup values. When you use a PSR-3 logger you need to choose a severity for each log message. PSR-3 has quite a few possible levels, but I'd like to propose that we really only need 4 to start with in MediaWiki: * debug: Useful for ummm debugging. :) These are messages that are useful for local development and are generally too spammy to output on a production wiki. This would typically include anything currently being logged via wfDebug. * info: Valuable state change information. This level is a great place to record information that would be useful in a production environment when tracing the path of a request that eventually had an error. * warning: A soft error condition such as a recoverable error or another condition that typically should not be seen but isn't halting for the operation in process * error: A hard error such as a caught exception with no recovery path. The notice, critical, alert and emergency log levels seem unnecessary to me, but I'm willing to hear arguments about where they are super duper useful for some log event state that I haven't thought of yet. When thinking about Wikimedia cluster logging, events emitted at warning and error levels should be things that you want deployers and operations staff to see in the Logstash fatalmonitor view and recorded to other durable logging stores. Events at info level may or may not be captured similar to how we currently enable some but not all wfDebugLog channels. Events at debug level will probably only be captured in beta labs and similar low volume debugging environments. The wfDebug* methods are not being deprecated officially yet but it would be great if people started treating them like they were deprecated when writing new classes. It would be even more awesome if more folks started making small cleanup patches to convert existing classes to the new style of logging. Tagging gerrit reviews for these patches with PSR-3 as either a submitter or a reviewer would also be appreciated. [0]: https://gerrit.wikimedia.org/r/#/c/119940/ [1]: https://gerrit.wikimedia.org/r/#/c/185210/ [2]: https://gerrit.wikimedia.org/r/#/c/184830/ [3]: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:master+topic:PSR-3,n,z 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting debug logging to PSR-3
Thanks Bryan, it is great to see this happening! On Thu, Jan 29, 2015 at 11:45 PM, Bryan Davis bd...@wikimedia.org wrote: PSR-3 logging has been fully supported in MediaWiki since1.25wmf5. When thinking about Wikimedia cluster logging, events emitted at warning and error levels should be things that you want deployers and operations staff to see in the Logstash fatalmonitor view and recorded to other durable logging stores. Events at info level may or may not be captured similar to how we currently enable some but not all wfDebugLog channels. Events at debug level will probably only be captured in beta labs and similar low volume debugging environments. Monolog has a logger called FingersCrossed which buffers info level events and logs them together with the next error (or discards them at the end of request if there is no error). Might be useful for debugging, although it would increase disk space and memory use. The wfDebug* methods are not being deprecated officially yet but it would be great if people started treating them like they were deprecated when writing new classes. So why not actually deprecate them? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Language Extension Bundle 2015.01 release
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2015.01. This bundle is compatible with MediaWiki 1.23.8 and
MediaWiki 1.24.1 releases.
* Download:
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.01.tar.bz2
* sha256sum: 7a53ed826ae14ffe279fc4231cc47d367f668723a5843ad62c13a8f17d339744
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CLDR and CleanChanges ==
* Localisation updates only.
== LocalisationUpdate ==
* T69154: Added support for updating skins.
== Translate ==
* T44162: Patrol footer will not appear on translation pages now.
* T76731: Added Content Translation Machine Translation backend support.
* T86000: Message group configurations are now optionally validated.
* Make 'fuzzy' as a default action for changes in source language in
Special:ManageMessageGroups.
== UniversalLanguageSelector ==
* This version has compatibility issues with Internet Explorer 8.
Support will be restored in the next MLEB release.
=== Input Methods ===
* Corrected names of Punjabi input methods.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] From Node.js to Go
Hmm, IIRC using Hack means you can't use xdebug with Zend PHP ... is debugging with HHVM in PhpStorm possible yet/soon? (I just figured out the debugger setup with Zend PHP and MediaWiki-Vagrant, and it's wonderful to have a debugger in PHP :D ) -- brion On Fri, Jan 30, 2015 at 11:14 AM, Chad innocentkil...@gmail.com wrote: On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis bd...@wikimedia.org wrote: On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdoug...@wikimedia.org wrote: I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options. Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch? I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think. Yeah, I'd -2 anything that required Hack in core. However if an extension wants to experiment they probably could. I was already thinking of trying some Hack in something WMF-specific like a Wikimedia* extension. -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] Urlencoding strip markers
On Fri, Jan 30, 2015 at 2:02 PM, Brion Vibber bvib...@wikimedia.org wrote: On Thu, Jan 29, 2015 at 5:38 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Thu, Jan 29, 2015 at 2:47 PM, Arlo Breault abrea...@wikimedia.org wrote: https://gerrit.wikimedia.org/r/#/c/181519/ To clarify, the possible solutions seem to be: 1. Unstrip the marker and then encode the content. This is a security hole (T73167) I'd be inclined to unstrip the marker *and squash HTML to plaintext*, then encode the plaintext... I don't see how that addresses the security issue. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] From Node.js to Go
On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdoug...@wikimedia.org wrote: I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options. Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch? I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think. Changing from PHP to Hack only requires changing the opening `?php` to `?hh`. Today what Hack gives you is some syntactic sugar for various common idioms from the Facebook internal code base and much stronger typing. The last time I saw someone asking if it was faster on #hhvm the answer was not yet. Whether strong typing is a pro or a con of Hack vs PHP seems like a religious debate that I'll try to stay out of until the issue is forced. The bits most likely to be of interest in the short term are the `async` and `await` keywords [0] and possibly the Continuation class [1] which makes creating generators easier than the PHP Iterator interface. [0]: http://docs.hhvm.com/manual/en/hack.async.php [1]: http://docs.hhvm.com/manual/en/hack.continuations.php 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
Re: [Wikitech-l] From Node.js to Go
On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis bd...@wikimedia.org wrote: On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdoug...@wikimedia.org wrote: I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options. Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch? I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think. Yeah, I'd -2 anything that required Hack in core. However if an extension wants to experiment they probably could. I was already thinking of trying some Hack in something WMF-specific like a Wikimedia* extension. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] DevSummit appreciation
Thanks again to the Foundation for inviting volunteers ( like me ) to the summit. It was a great experience to see my mentors and other guys in IRC off-line face to face for the first time. Regarding the BounceHandler extension - I could get various inputs from other devs who had implemented the same in their environment. The stay and location was superb. I missed some Indian foods though ( thanks to the fruits ). Our deployment plans got delayed due to the security bug that came, making the Ops team busy. We hope to get it done this week though. Thanks again Qum and Rachel and other staff+volunteers for such a great event. Thanks, Tony Thomas http://tttwrites.wordpress.com/ FOSS@Amrita http://foss.amrita.ac.in *where there is a wifi, there is a way* On Fri, Jan 30, 2015 at 4:04 AM, Rob Lanphier ro...@wikimedia.org wrote: Huge +tons to everything below (and top posting to drive Mz up the wall) :-) As Erik said, I know I'm probably going to be driving Rachel and Quim nuts with my handwringing and second guessing as we figure out the pros and cons of how things went this year so that we can keep improving this. But, both of them (and everyone they pulled in) worked like hell put on a great show, and gave us a wonderful space to have some great conversations about our future engineering direction. Thank you! Rob On Wed, Jan 28, 2015 at 9:15 AM, Brion Vibber bvib...@wikimedia.org wrote: Agreed - we had a great space and good support, the WiFi worked, power strips everywhere, and there was always coffee. I can ask for little more... ;) Thanks also to our fellow attendees -- I had a lot of great conversations and got a lot of data points to help set my work directions for the coming months. Everybody there was awesome even when we had contentious issues -- I want to thank everybody for having a positive attitude and working together. -- brion On Jan 27, 2015 10:44 PM, Erik Moeller e...@wikimedia.org wrote: Just a quick note that I really appreciated everyone's help making the summit come together. As always, we'll be doing lots of second-guessing of everything we did and didn't do, and how we want to use future time together. Before we go into that, I'd like to thank the event team and _everyone_ who worked to and beyond the point of exhaustion to organize the event, support attendees, plan sessions, facilitate conversations, negotiate sometimes difficult terrain. Thank you. :) Erik -- Erik Möller VP of Product Strategy, Wikimedia Foundation ___ Engineering mailing list engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Add members to extension owners
What is the process to add people as owners of an extension? What is described on mw.org [0] does not work. Contrary to what is written there I can not add group members myself to a group that I am in. And a request I added there is open now for more than three months. So, what do I have to do to give other people access to extensions? Are there any plans to streamline that process? Stephan http://www.mediawiki.org/wiki/Gerrit/Project_ownership#To_make_a_new_Project_Owner ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Blog post on Librarization project published
Congrats to Bryan, Chad, Kunal, Robla -- and all the folks who contributed to this story and to this project! Gilles, thanks for pointing out the typo, which I just fixed: http://blog.wikimedia.org/2015/01/29/modernizing-mediawiki-with-libraries/ We’d love to publish more tech reports like this on the blog this year. Please contact me if you’d like to write about new breakthroughs or lessons learned that would interest a broad audience on the blog. All the best, Fabrice On Jan 29, 2015, at 8:14 PM, Gilles Dubuc gil...@wikimedia.org wrote: Great blog post and awesome achievements! I've spotted a small typo in the text: that offer more compelling featuresd. On Thu, Jan 29, 2015 at 5:01 PM, Bryan Davis bd...@wikimedia.org mailto:bd...@wikimedia.org wrote: For the last four months, my main focus has been the Librarization project [0]. Today a wrap up blog post was posted to blog.wikimedia.org http://blog.wikimedia.org/ [1] that I'd invite all of you to read to get an overview of what our high level goals and motivations were and what we accomplished. The TL;DR is that we now have some guidelines for how to separate code from MediaWiki and publish it as a semi-autonomous open source project. The blog post ends with a thinly veiled call to action for MediaWiki developers to continue the work of extracting code from the current MediaWiki core application and publishing them as independent libraries. We've published some information on how to deal with git hosting, code review, and various other general issues on mediawiki.org http://mediawiki.org/ [2]. There is also a list of some areas of the existing code base that we thought would be interesting targets for extraction [3]. The CDB library [4] can serve as one concrete example of using the guidelines. I'd like to invite anyone interested in starting work on decoupling a particular area of the code to start a thread on wikitech-l and file a task in Librarization phabricator project [5] to attract collaborators and help reduce possible duplication of effort. It would also be great to have edits on the list page and/or phabricator tasks to act as a wish list of things that know of in MediaWiki that you would either like to be able to use in a non-MediaWiki PHP project or feel would be a good candidate for isolation so that alternate implementations could be introduced. [0]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki [1]: https://blog.wikimedia.org/2015/01/29/modernizing-mediawiki-with-libraries/ https://blog.wikimedia.org/2015/01/29/modernizing-mediawiki-with-libraries/ [2]: https://www.mediawiki.org/wiki/Manual:Developing_libraries https://www.mediawiki.org/wiki/Manual:Developing_libraries [3]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki/Library_list https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki/Library_list [4]: https://www.mediawiki.org/wiki/CDB https://www.mediawiki.org/wiki/CDB [5]: https://phabricator.wikimedia.org/tag/librarization/ https://phabricator.wikimedia.org/tag/librarization/ Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org mailto:bd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 tel:415.839.6885%20x6855 ___ Engineering mailing list engineer...@lists.wikimedia.org mailto:engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering https://lists.wikimedia.org/mailman/listinfo/engineering ___ Engineering mailing list engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
