Re: [Wikitech-l] Config class and 1.23
On 5/23/14, 9:26 PM, Legoktm wrote: On 4/29/14, 1:56 PM, Sumana Harihareswara wrote: Looks like we are still working on merging the Make abstract Config class truly implementation-agnostic changeset.[0] [0] https://gerrit.wikimedia.org/r/#/c/109850/ The patch currently has three +1's (including myself) and one -1; it's just waiting for someone to +2 it :) Super-delayed update: Tyler merged the patch, and it was backported into 1.23. Thanks to everyone who contributed during the 4 month journey of the patchset! Now, we begin the fun part of migrating our code to use the new classes. Reedy has [1] open which switches all of core's API to use it, and I've submitted [2] for MassMessage. I've also written up some basic documentation[3] about how to migrate to the new classes. [1] https://gerrit.wikimedia.org/r/#/c/109271/ [2] https://gerrit.wikimedia.org/r/#/c/137216/ [3] https://www.mediawiki.org/wiki/Manual:Configuration_for_developers -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC] Extension registration
On Wed, Jun 4, 2014 at 10:29 AM, Legoktm legoktm.wikipe...@gmail.com wrote: == Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions. How about a library that registers resources in ResourceLoader (we have that a lot for Wikidata.org)? Currently they would be installed to $IP/vendor. Should they all be regarded as a MediaWiki extension just because they (also) support ResourceLoader? […] IMO MediaWiki should do the extension loading on its own, and not require the user to put a function call in their configuration. I'm not too sure about that one. I think having the code for something installed without actually running it has its use cases. For example, you find an issue with an extension but have no time to investigate it right now. Having all extensions automatically loaded if they are present would force you to uninstall the extension to disable it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC] Extension registration
On 6/4/14, 1:42 AM, Adrian Lang wrote: […] IMO MediaWiki should do the extension loading on its own, and not require the user to put a function call in their configuration. I'm not too sure about that one. I think having the code for something installed without actually running it has its use cases. For example, you find an issue with an extension but have no time to investigate it right now. Having all extensions automatically loaded if they are present would force you to uninstall the extension to disable it. Sorry, I should have been more clear about this. I didn't mean autoloading in the sense of if the extension is present, MediaWiki will automatically enable it. What I meant was, that if your configuration has: $wgEnabledExtensions[] = 'Math'; You shouldn't *also* have to write: wfLoadExtensions(); Just the first alone should be necessary. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC] Extension registration
On 2014-06-04, 1:29 AM, Legoktm wrote: A few more updates about the RfC after the IRC meeting. In case you missed it, the logs are at [1]. == Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions. I still do NOT like this idea. By all means there should be one directory for extensions that are managed by a web/cli installer and the method of loading extensions from that one directory should be simple even when we're still using a php settings file. But when someone is intentionally not using that and doing complex config then we shouldn't stop them from saying to load an extension from a specific directory. A few other options were discussed in the meeting: wfEnableExtension( 'Math' ); $wgMathSomeOption = 'bar'; Where the function sets the default globals, and then the user overwrites them. This won't work for when we want to store configuration in the database since extensions to be loaded are no longer in an array. I don't understand where you get this assertion, this should have no effect on whether we can or can't have config in the DB. A wfEnableExtension would do the exact same thing as $wgEnabledExtensions would do to load an extension, just earlier. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New tabs for images
On Sun, Jun 1, 2014 at 1:17 PM, bawolff bawolff...@gmail.com wrote: On Jun 1, 2014 5:12 AM, ENWP Pine deyntest...@hotmail.com wrote: So here I am working late night / early morning trying to get the Signpost published, and I see something new at the top of image pages on English Wikipedia such as https://en.wikipedia.org/wiki/File:Wikidata.png We now have View on Wikimedia Commons and Add local description tabs. Cool! I agree. Thank you This,_that_and_the_other for making that feature happen. Except that now (with Media Viewer deployed), the local file description page is no longer accessible, so this new feature is practically useless. -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New tabs for images
It is still accessible, It's just a utter pain to get to. On 4 June 2014 20:35, Petr Kadlec petr.kad...@gmail.com wrote: On Sun, Jun 1, 2014 at 1:17 PM, bawolff bawolff...@gmail.com wrote: On Jun 1, 2014 5:12 AM, ENWP Pine deyntest...@hotmail.com wrote: So here I am working late night / early morning trying to get the Signpost published, and I see something new at the top of image pages on English Wikipedia such as https://en.wikipedia.org/wiki/File:Wikidata.png We now have View on Wikimedia Commons and Add local description tabs. Cool! I agree. Thank you This,_that_and_the_other for making that feature happen. Except that now (with Media Viewer deployed), the local file description page is no longer accessible, so this new feature is practically useless. -- [[cs:User:Mormegil | Petr Kadlec]] ___ 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] Zuul upgraded
Hello, I have upgraded Zuul (our gateway between Jenkins and Gerrit) a few minutes a go. The main change is that the merge of patches with tip of the target branch is now done in a different process (zuul-merge). Beside that new feature, I don't expect any trouble. But we never know hence this short announcement =) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC] Extension registration
Date: Wed, 04 Jun 2014 02:12:30 -0700 From: Daniel Friesendan...@nadir-seen-fire.com On 2014-06-04, 1:29 AM, Legoktm wrote: == Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions. I still do NOT like this idea. By all means there should be one directory for extensions that are managed by a web/cli installer and the method of loading extensions from that one directory should be simple even when we're still using a php settings file. But when someone is intentionally not using that and doing complex config then we shouldn't stop them from saying to load an extension from a specific directory. +1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using Composer to manage libraries for mediawiki/core on Jenkins and Foundation cluster
Starwman. I happen to have discussed the situation and the approach with the main people behind Composer in person, as well as gone over details with contributors on IRC. They did not seem to share your opinion. Since we’re throwing out logical fallacies: argumentum ab auctoritate. Like I’ve *already explained*… Here is the problem: we need composer.json and composer.lock to be version controlled so that MediaWiki core can manage its own dependencies rather than using git submodules or hard-copying source trees into the repository, which everybody agrees are not sustainable solutions. However, third parties want to be able to install extensions via Composer, which, while not the purpose of Composer, is technically feasible. These two ideas conflict. Here is the solution: rather than using Composer as a package management system when, in reality, it is a dependency management system, we use Composer to properly maintain core, and then do one of the following: 1) implement our own extension installation system from scratch, or 2) change and/or extend Composer so that it supports a plugin system. I personally recommend the latter, and there are upstream bug reports open concerning it. -- Tyler Romeo 0xC86B42DF signature.asc Description: Message signed with OpenPGP using AMPGpg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] enwiki display issues
Regarding the May 16 issue with the bits.wikimedia.org cluster (which was affecting availability of various modules, including gadgets), that is filed as bug 65424. https://bugzilla.wikimedia.org/show_bug.cgi?id=65424. Server admin log entries during the incident: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Logdiff=113204oldid=113199 I documented the incident just now: https://wikitech.wikimedia.org/wiki/Incident_documentation/20140517-bits — Krinkle On 1 Jun 2014, at 17:22, Helder . helder.w...@gmail.com wrote: On Sat, May 31, 2014 at 1:21 PM, Andre Klapper aklap...@wikimedia.org wrote: On Sat, 2014-05-31 at 07:52 -0300, Helder . wrote: Shouldn't we have an incident report[1] about this? https://wikitech.wikimedia.org/wiki/Incident_documentation/20140529-appservers (as mentioned in the other thread) That link is about a recent problem, not about the gadgets problem from 16 may. Helder ___ 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] Using Composer to manage libraries for mediawiki/core on Jenkins and Foundation cluster
On Wed, Jun 4, 2014 at 9:53 AM, Tyler Romeo tylerro...@gmail.com wrote: Here is the solution: rather than using Composer as a package management system when, in reality, it is a dependency management system, we use Composer to properly maintain core, and then do one of the following: 1) implement our own extension installation system from scratch, or 2) change and/or extend Composer so that it supports a plugin system. I personally recommend the latter, and there are upstream bug reports open concerning it. As a temporary workaround, maybe we could create extensions/composer-example.json which could be used for extension registration by running composer in that directory? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using Composer to manage libraries for mediawiki/core on Jenkins and Foundation cluster
As a temporary workaround, maybe we could create extensions/composer-example.json which could be used for extension registration by running composer in that directory? Yes. That would work. All we would need to do is add the following into Setup.php: include “$IP/extensions/vendor/autoload.php”; (Obviously we’d also have a file_exists check…) -- Tyler Romeo 0xC86B42DF signature.asc Description: Message signed with OpenPGP using AMPGpg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] learning Ops infrastructure (was: Re: 404 errors)
Thanks Sumana, That's good info to have. I'll look through those links. That diagram may make its way into the presentation that I'm drafting. The presentation has balooned to an alarming length already but I'm going to try to complete it in outline form before pruning. If someone else makes presentation slides available about infrastructure under a license that allows reuse I would greatly appreciate it. By the way, I appreciated the overview of UX in your keynote [1]. Pine [1] http://wiki.code4lib.org/index.php/2014_Keynote_by_Sumana_Harihareswara Date: Tue, 03 Jun 2014 09:41:34 -0400 From: Sumana Harihareswara suma...@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] learning Ops infrastructure (was: Re: 404 errors) Message-ID: 538dd08e.1000...@wikimedia.org Content-Type: text/plain; charset=UTF-8 Hi, Pine. I, too, am interested in building our understanding of our TechOps infrastructure. https://www.mediawiki.org/wiki/Presentations has some explanations of some parts, as does http://wikitech.wikimedia.org/ . I welcome more links to guides/overviews. At the recent Zurich hackathon, other developers agreed that it would be good to have a guide to Wikimedia's digital infrastructure, especially how MediaWiki is used. https://www.mediawiki.org/wiki/Overview_of_Wikimedia_infrastructure is a homepage with approximately nothing on it right now except this diagram of our server architecture: https://commons.wikimedia.org/wiki/File:Wikimedia_Server_Architecture_%28simplified%29.svg You might find the Performance Guidelines illuminating https://www.mediawiki.org/wiki/Performance_guidelines and you might also like the recent tech talk about how we make Wikipedia fast, by Ori Livneh and Aaron Schulz, recently - see http://www.youtube.com/watch?v=0PqJuZ1_B6w (I don't know when the video is going up on Commons). -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation On 05/30/2014 06:30 PM, ENWP Pine wrote: Ori, thanks for following up. I think I saw somewhere that there is a list of postmortems for tech ops disruptions that includes reports like this one. Do you know where the list is? I tried a web search and couldn't find a copy of this report outside of this email list. I personally find this report interesting and concise, and I am interested in understanding more about the tech ops infrastructure. Reports like this one are useful in building that understanding. If there's an overview of tech ops somewhere I'd be interested in reading that too. The information on English Wikipedia about WMF's server configuration appears to be outdated. Thanks, Pine ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML templating decision soon?
In the meantime, some developers (such as the Mobile and Flow teams) have short-term needs that can't wait up for Knockoff to become a complete solution, and so are working out interim standardizations outside of this mailing list so that they can move forward while Knockoff work continues. The first iteration of the implementation has actually been complete for a while now, see Matt's mail here on April 14 [0]. There's a JS implementation of the KnockOff compiler [1] and JS [2] and PHP [3] implementations of the TAssembly runtime. We are waiting for feedback before starting the second iteration. At least the mobile team had plans for giving it a spin, but I have not heard about that since. For client-side templating you need ResourceLoader to supply the templates to the client. Jon Robson has developed the Mantle extension[1] that implements * a ResourceLoaderTemplateModule that does this * JS functions that abstract getting a template, compiling and caching it, and rendering it * specific implementations of these functions for the handlebars and hogan JS libraries. MobileFrontend and Flow will start using this shared code in production in the next few weeks or so. In order for Flow to share templates between front-end JS and server PHP, Flow has had to write helper functions in both JS and PHP[2]. Some like message i18n, human-friendly timestamps, escaping, etc. are more generic than others. These experiences in generalized JS template support and developing helper functions across JS and PHP could inform Knockoff development. Yes, large parts of this infrastructure will be useful with Knockoff / TAssembly as well. Should I be saying Knockoff or Knockout? From the RFC page, Gabriel WIcke Matthew Walker's Knockoff templates are KnockoutJS compatible. AIUI, GWMW have a JS compiler that compiles them into GWMW's Knockoff - Tassembly intermediate representation, and their goal is to to render templates in the latter format from both PHP and JavaScript. KnockOff is the KnockOut template to TAssembly compiler, while TAssembly is the JSON-based intermediate format with runtimes in JS PHP. In JavaScript you'd still load the Knockout JS for its reactive model-view updates. This is possible due to the shared template syntax, but not necessary. If reactivity is not needed performance / size is a priority then using the TAssembly runtime might make more sense. It's a lot smaller faster. KnockOff TAssembly are a part of the longer-term vision of moving to HTML as our primary content representation. I have started to draft a high-level overview at [4]. We (the new service team [5]) plan to explore this further in collaboration with the Parsoid team. Gabriel [0]: http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075995.html [1]: https://github.com/gwicke/knockoff [2]: https://github.com/gwicke/tassembly [3]: https://github.com/mattofak/knockoff [4]: https://www.mediawiki.org/wiki/HTML_content_templating [5]: https://www.mediawiki.org/wiki/Wikimedia_Engineering/Service_and_REST_API_team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Upcoming jQuery upgrade (breaking change)
On 06/03/2014 09:04 PM, James Forrester wrote: There have been a number of high-profile semi-announcements as well as comments and code reviews relating to this, most obviously this one: http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064280.html True, that's only one piece ($.browser) of it, though. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
