Wikitech-l September 2014

wikitech-l@lists.wikimedia.org

129 participants
127 discussions

RFC meeting today
by Tim Starling 22 Sep '14

22 Sep '14

This week only, we will have a Thursday 21:00 UTC meeting to discuss Aude's proposed Linker refactor: <https://www.mediawiki.org/wiki/Requests_for_comment/Linker_refactor> The time is: * UTC: Thursday 21:00 * US PDT: Thursday 14:00 * Europe CEST: Thursday 23:00 * Australia AEST: Friday 07:00 Next week, it will be back to the usual time of Wednesday UTC. A few hours ago, we discussed Andrew Wight's RFC "Page protection as a component", with the few people who were in #wikimedia-office at the usual time despite no meeting being announced. My apologies for the lack of an announcement. Logs are available at: <https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.20…> -- Tim Starling

2 1

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 21 Sep '14

21 Sep '14

1 0

ANN: Version 1.0.0 of the Memento Headers Extension
by Shawn Jones 21 Sep '14

21 Sep '14

All, Thanks to new architecture developments within the Memento Project, we are pleased to announce the availability of Version 1.0.0 of the Memento Headers time travel Extension for MediaWiki. The extension can be downloaded via [1]. Information on the extension is available at [2]. A demonstration wiki equipped with the extension is available at [3]. This extension only supplies the headers necessary to work with Memento clients [4], and does not provide all of the features of Memento for a MediaWiki installation. it relies upon an external TimeGate server, provided online by the Memento Project, to actually provide the datetime negotiation necessary for web time travel. Memento clients allow one to select a past date and time to browse, and then browse the web as if it were that date and time. Installing the Memento Headers extension in a MediaWiki installation allows Memento clients to seamlessly transition from using web archives to wikis, allowing one to view past versions of web pages without interruption. Earlier today, we announced the availability of version 2.1.0 of the full Memento extension. That extension provides additional functionality, such as ensuring that old revisions of images and templates match the revision of the page in which they are embedded. The Memento Headers extension does NOT provide such functionality. The Memento Headers extension only provides the headers necessary for Memento clients to find the oldid pages in MediaWiki installations that best match the datetime requested by the user. As noted in the earlier announcement, the Memento protocol is currently used by major web archives [5] and supported by the International Internet Presevation Consortium [6]. Though we have the support of web archives, the Memento team also considers time travel in MediaWiki to be a major use of the protocol. Videos [7] and [8] show Memento at work in the web at large, the latter paying attention to navigation within Wikipedia. Video [9] shows Memento at work in the full Memento MediaWiki extension. We really look forward to any feedback the Wikimedia community can provide on this new exciting (though limited) way to provide and experience Memento. On behalf of the Memento Team, Shawn M. Jones Graduate Research Assistant Department of Computer Science Old Dominion University Email: sjone(a)cs.odu.edu Research group: http://ws-dl.blogspot.com Twitter: @shawnmjones — [1] https://github.com/mementoweb/mediawiki-memento-headers/releases/tag/v1.0.0 [2] https://www.mediawiki.org/wiki/Extension:MementoHeaders [3] http://ws-dl-05.cs.odu.edu/demo-headers/index.php/Main_Page [4] http://bit.ly/memento-for-chrome [5] http://mementoweb.org/depot/ [6] http://netpreserve.org/ [7] http://www.youtube.com/watch?v=0_70lQPOOIg [8] http://www.youtube.com/watch?v=WtZHKeFwjzk [9] https://www.youtube.com/watch?v=ciClYjTnscs

1 0

ANN: Version 2.1.0 of the Memento MediaWiki Extension
by Shawn Jones 21 Sep '14

21 Sep '14

All, Thanks to a few informal code reviews, version 2.1.0 of the Memento time travel Extension for MediaWiki has been released. The extension can be downloaded via [1]. Information on the extension is available at [2]. A demonstration wiki equipped with the extension is available at [3]. This release incorporates changes to enrich the code based on additional review and feedback from members of the WikiMedia team. The extension fixed a few bugs, now supports the newer JSON-based i18n system, and has removed three configuration options in order to streamline the code. We fully appreciate the feedback we’ve received and appreciate any additional feedback the community can provide. Our goal is to make the extension as solid as possible for MediaWiki users everywhere. The extension works with Memento clients [4]. Memento clients allow one to select a past date and time to browse, and then browse the web as if it were that date and time. Installing this extension in a MediaWiki installation allows Memento clients to seamlessly transition from using web archives to wikis, allowing one to view the past versions of web pages without interruption. This has numerous applications, from avoiding spoilers [5] to studying the evolution of legal discourse. Additionally, this extension attempts to address the issue of "temporal coherence", ensuring that old revisions of images and templates match the revision of the page they are embedded in. This functionality is still optional and experimental, but has received some interest from the community. Earlier this summer, we presented our experiences with reconstructing the past using MediaWiki [6, 7], and demonstrated using the extension to avoid spoilers in Game of Thrones [8, 9, 10] at WikiConference USA 2014. The extension is fully compliant with RFC 7089 [11], which specifies the Memento protocol. The effort was supported in part by the Andrew W. Mellon Foundation and is a joint effort between Old Dominion University and Los Alamos National Laboratory. Videos [12] and [13] show Memento at work in the web at large, the latter paying attention to navigation within Wikipedia. The Memento protocol is currently used by major web archives [14] and supported by the International Internet Presevation Consortium [15]. Though we have the support of web archives, the Memento team also considers time travel in MediaWiki to be a major use of the protocol. We really appreciate the feedback from the Wikimedia team and look forward to additional assistance and improvements. Thank you again, on behalf of the Memento Team, Shawn M. Jones Graduate Research Assistant Department of Computer Science Old Dominion University Email: sjone(a)cs.odu.edu Research group: http://ws-dl.blogspot.com Twitter: @shawnmjones — [1] https://github.com/mementoweb/mediawiki/releases/tag/v2.1.0 [2] https://www.mediawiki.org/wiki/Extension:Memento [3] http://ws-dl-05.cs.odu.edu/demo/ [4] http://bit.ly/memento-for-chrome [5] http://ws-dl.blogspot.com/2013/12/2013-12-18-avoiding-spoilers-with.html [6] http://wikiconferenceusa.org/wiki/Submissions:Reconstructing_the_past_with_… [7] http://www.slideshare.net/shawnmjones/reconstructing-the-past-with-media-wi… [8] http://wikiconferenceusa.org/wiki/Submissions:Using_the_Memento_Mediawiki_E… [9] http://www.slideshare.net/shawnmjones/using-the-memento-mediawiki-extension… [10] https://www.youtube.com/watch?v=ciClYjTnscs [11] http://tools.ietf.org/html/rfc7089 [12] http://www.youtube.com/watch?v=0_70lQPOOIg [13] http://www.youtube.com/watch?v=WtZHKeFwjzk [14] http://mementoweb.org/depot/ [15] http://netpreserve.org

1 0

Re: [Wikitech-l] [Wikimedia-l] Invitation to beta-test HHVM
by Pine W 21 Sep '14

21 Sep '14

Just a few thoughts: * I agree that the tone of the email that started this discussion about software quality standards was unnecessarily critical. Even in production releases, users may find occasional bugs. * The intent of HHVM implementation and James' quick response to the problem report are nice to see. * The perfect should not be the enemy of the good, especially for opt-in pre-production releases. * Regarding standards for different release phases, I would need to think more about that but hope that someone will set up a proposed checklist on MediaWiki.org. We have some quality experts like Chris McMahon and their input would be helpful. Pine

1 0

Re: [Wikitech-l] [Wikimedia-l] Invitation to beta-test HHVM
by Pine W 21 Sep '14

21 Sep '14

Thanks, but I'm looking for something that is more specific to MediaWiki and that commits development teams to specific, standardized, and transparently measured quality metrics as products advance or regress in their path to production release. Pine

3 2

Re: [Wikitech-l] [Wikimedia-l] Invitation to beta-test HHVM
by Pine W 21 Sep '14

21 Sep '14

Given longtime experience with problematic releases of MediaWiki features, I think that published quality standards that products must meet in order to become production releases could help to limit the number and seriousness of additional troubled launches. These standards would also reduce the ambiguity around terms like alpha and beta. Pine

1 0

[BREAKING CHANGE] Deprecated JavaScript methods to be removed in MediaWiki 1.25
by Krinkle 20 Sep '14

20 Sep '14

TL;DR: * Several deprecated methods in MediaWiki's JavaScript modules will be removed in a few weeks' time. * Ensure your code no longer uses these methods and update it if needed. * Check and fix any gadgets or scripts you or your wikis rely upon. As part of the regular update cycle, a number of deprecated methods in our JavaScript modules will be removed in the MediaWiki 1.25 release. This is an announcement to give people notice they should update any extensions, gadgets and scripts they have written, maintain, or rely upon. Usually we don't give this much attention to removal of deprecated methods, but due to this being our first proper development cycle for our front-end code base, I want to make sure this reaches everyone. You're likely not yet in the habit of updating front-end code between MediaWiki releases. Deprecated methods to be removed in MediaWiki 1.25: * Remove mw.user.name() method. [1] Deprecated since MediaWiki 1.20. Use mw.user.getName() instead. * Remove mw.user.anon() method. [1] Deprecated since MediaWiki 1.20: Use mw.user.isAnon() instead. * Remove mediawiki.api methods' "ok" and "err" callback parameters. [2] Deprecated since MediaWiki 1.23. Use the returned Promise interface instead. * Remove mediawiki.api.category "async" parameter. [2] Deprecated since MediaWiki 1.23. The ability to override $.ajax() to be synchronous has been removed. The default (asynchronous) behaviour remains. Use the Promise interface to retreive the fetched data from the API. * Remove jquery.json module. Deprecated since MediaWiki 1.24. [3] Use standardised JSON.stringify and JSON.parse methods. And depend on the "json" module which will automatically load a polyfill in older browsers. ## Timeline These removals will land in MediaWiki 1.25alpha in early October 2014, and deployed to Wikimedia wikis the week after from October 4th onwards (1.25wmf2). The MediaWiki 1.25.0 stable release is expected to come out around April 2015. You should make sure that your code is updated before your wiki upgrades to MediaWiki 1.25. If you know code you rely upon will be affected but don't know how to fix it, please check with your wiki's community for local experts. If none of them can help, you can ask for assistance on the wikitech-ambassadors mailing list. [5] ## Reminders In case you've missed the previous announcements: * The migration period for jQuery core is still on-going and is also scheduled for MediaWiki 1.25. [4] More about that in the mail from June 2014: https://www.mail-archive.com/mediawiki-l%40lists.wikimedia.org/msg13651.html * Learn about deprecation notices and how you can see them in your browser. https://www.mail-archive.com/wikitech-l%40lists.wikimedia.org/msg72198.html [1] https://gerrit.wikimedia.org/r/#/c/111422/ [2] https://gerrit.wikimedia.org/r/#/c/118733/ [3] https://gerrit.wikimedia.org/r/#/c/140560/ [4] https://gerrit.wikimedia.org/r/#/c/137168/ [5] https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors -- Krinkle PS: You can get a sense of the progress on our different migrations, past and present, via these graphs: http://codepen.io/Krinkle/full/zyodJ/

1 0

Re: [Wikitech-l] [Wikimedia-l] Invitation to beta-test HHVM
by Guillaume Paumier 20 Sep '14

20 Sep '14

Hello, On Sat, Sep 20, 2014 at 9:32 PM, Rand McRanderson <therandshow(a)gmail.com> wrote: > Here is one idea. A dashboard of top level Wikimedia projects with > statuses, estimates, and a key to terms. Or does this exist? There is https://www.mediawiki.org/wiki/Wikimedia_Engineering/Dashboard It doesn't have everything you mentioned, but we can build on it and improve it. -- Guillaume Paumier

1 0

Fixing PollNY -- ResourceLoader woes
by Jack Phoenix 20 Sep '14

20 Sep '14

Hi all, A few days ago I was fiddling around with my Labs instance [1], which serves as a development/testing/showcase area for social tools [2]. Somehow I ended up on Special:ViewPoll [3] and got curious as to why a JavaScript hover effect (mouseover/mouseout) didn't work on that page -- I was sure it used to work just fine not that long time ago. Without thinking that much about it, I clicked on the one and only poll listed on the page [4], and turns out the whole Poll: page is about as broken as it can be due to a JavaScript error. After a while of debugging, consultation and more debugging, turned out that my local development setup had $wgResourceLoaderDebug = true; in its LocalSettings.php, which apparently hides some race conditions or something like that. The Labs instance tries to be a more faithful representation of a production wiki, and as such, it doesn't have this setting enabled and hence why the problem manifests there. PollNY itself is a rather old extension, as most original social tools are (see the MW.org page [2] for details), and as such, it likely has some non-optimal code and it's also gone through plenty of iterations in the past. As a matter of fact, when porting PollNY to use ResourceLoader, it seems I myself made some suboptimal choices, such as bundling both CSS and JS into the same module and loading this module with 'position' => 'top'. Anyway, after decoupling the main CSS into its own module (locally, haven't submitted this to git yet), tweaking the callers and whatnot, I was able to get the hover effects on Special:ViewPoll to work as intended. While this is definitely a step forward, the actual problem with pages in the Poll: namespace still persists. PollNY has two JS files, LightBox.js and Poll.js. LightBox.js contains a lightbox implementation and technically it's not needed for stuff like the <pollembed> tag etc. and it should only be loaded on Poll: pages. Poll.js, on the other hand, is basically needed everywhere where there is PollNY; special pages, pages that embed a poll via the <pollembed> tag, Poll: pages... Now, the actual issue is that no matter what I do, I get a "TypeError: 'LightBox' is not defined" on Poll: pages (such as [4]). In the git master version, this is due to the aforementioned race condition: line 466 of Poll.js tries to use mw.loader.load() to load the LightBox RL module if it's not already loaded, but in RL's production mode this fails, because, as I've been told by those with more intimate knowledge of ResourceLoader and its inner workings, mw.loader.load is asynchronous. I've tried mw.loader.using, but it doesn't seem to do anything as far as fixing the issue goes. Please let me know if you're able to help me out with this; I've ran out of ideas. [1] http://social-tools.wmflabs.org/ [2] https://www.mediawiki.org/wiki/Social_tools [3] http://social-tools.wmflabs.org/wiki/Special:ViewPoll [4] http://social-tools.wmflabs.org/wiki/Poll:How_is_the_weather_today%3F Thanks and regards, -- Jack Phoenix MediaWiki developer

4 7

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 20 Sep '14

20 Sep '14

Minutes and slides from Wednesday's quarterly review meeting of the Foundation's Growth team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

1 0

Re: [Wikitech-l] [Wikimedia-l] Invitation to beta-test HHVM
by Pine W 20 Sep '14

20 Sep '14

Do we have a published guideline somewhere about MediaWiki quality standards for pre-alpha, alpha, beta, and production releases of elements like MediaViewer, VisualEditor, Flow, Winter, and HHVM? Pine On Sep 20, 2014 12:14 AM, "Jon Work" <jon.davies(a)wikimedia.org.uk> wrote: > :} I am always impressed by those of you for whom English is not your > native tongue. It can be very complicated to understand some of the > shortcuts we use. > > Sent from my iPad > > > On 20 Sep 2014, at 02:22, MZMcBride <z(a)mzmcbride.com> wrote: > > > > Anders Wennersten wrote: > >> I also did soma very subjective test on response times and found the new > >> feature to give 1-3 s quicker response, which is quite much (6s-5s, > >> 7s-4s) and make a big difference in the user experience. > > > > Woo! :D > > > >> Also after reflecting on my little harsh reaction on the deployment > >> process, I wonder if it is not a language/communication issue > >> > >> Being a non-native English speaking person I must admit I have no idea > >> of the meaning "intrepid" means in "for intrepid beta testers". It > >> seems for Guillaume it means "hey this is badly tested, but use if you > >> have patience/courage" which I can accept as a message of a testrelease > >> > >> Also in my backgroud working in a company making internal deployment of > >> software for 4000 internal users, I am used of making a huge difference > >> in "ready for Alpha test" and "ready for Beta test", but perhaps my > >> reference frame is inappropriate in this case, where perhaps a beta > >> functionality means "Software for testing, not ready for release" and > >> covering both my distinctions > >> > >> So I apologize if I used too strong wordings and instead want to > >> congratulate you on releasing a good function where you so speedily > >> fixed the bug! > > > > No worries. Thank you for taking the time to write up this message > > explaining. I think there are definitely ways in which we can improve our > > communication about beta (or alpha!) features, including attempting to > > label them appropriately and making sure the message is suitably clear. > > Your constructive feedback will help us do better in the future. > > > > MZMcBride > > > > > > > > _______________________________________________ > > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > > Wikimedia-l(a)lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 0

OOjs, MobileFrontend and Flow
by Jon Robson 19 Sep '14

19 Sep '14

Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside the mobile and Flow projects. The following 3 patches kicks off moving MobileFrontend's class model towards that of oojs - many thanks for Roan for doing most of the legwork :-): https://gerrit.wikimedia.org/r/155593 https://gerrit.wikimedia.org/r/155589 https://gerrit.wikimedia.org/r/129336 On the long term we'd look to swap out the Class.js and eventemitter.js files in MobileFrontend for oojs, but this is going to be tricky and require some care, possibly mixing both oojs and MobileFrontend's class code in the repository at the same time. e.g. increasing JavaScript on the short term, but reducing it on the longterm. The MobileFrontend core development team will need to work out how best to manage this transition. Since Flow is very DOM-focused, as opposed to many smaller JavaScript modules with element management per the currently-accepted use of OOjs, it is unclear how we may go about integrating with OOjs fully. However, some potential use cases have been identified as candidates for implementing OOjs on an interim basis, primarily by abstracting some current FlowBoardComponent workflows, such as those which handle (re-)rendering of existing and new content fetched from the API.

3 6

Roadmap and deployment highlights - week of Sept 22nd
by Greg Grossmeier 19 Sep '14

19 Sep '14

Hello and welcome to the latest edition of the WMF Engineering Roadmap and Deployment update. The full log of planned deployments next week can be found at: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_22nd> A quick list of notable items... == Tuesday == * MediaWiki deploy ** group1 to 1.24wmf22: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf22> == Thursday == * MediaWiki deploy ** group2 to 1.24wmf22 (all Wikipedias) ** group0 to 1.24wmf23 (test/test2/testwikidata/mediawiki) Thanks and as always, questions and comments welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

oci_error() undefined error
by Bill Traynor 19 Sep '14

19 Sep '14

Installed MediaWiki (git master) with Oracle 11 as the database. Post installation, the MainPage does not display but shows instead: Warning: oci_parse() expects parameter 1 to be resource, boolean given in ...MediaWiki/includes/db/DatabaseOracle.php on line 1266 Warning: oci_error() expects parameter 1 to be resource, null given in ...MediaWiki/includes/db/DatabaseOracle.php on line 1271 Now, I assume I can ignore these warnings, so I attempted to run ../maintenance/update.php --quick and received: MediaWiki 1.24alpha Updater PHP Fatal error: Call to undefined function oci_error() in ...MediaWiki/includes/db/DatabaseOracle.php on line 522 Fatal error: Call to undefined function oci_error() in ...MediaWiki/includes/db/DatabaseOracle.php on line 522 The code at line 522 is: function lastError() { if ( $this->mConn === false ) { $e = oci_error(); } else { $e = oci_error( $this->mConn ); } return $e['message']; } Why isn't oci_error() defined if oci8 is installed?

1 0

Jenkins smarter with extension PHPUnit tests
by Antoine Musso 19 Sep '14

19 Sep '14

Hello, An hour or so ago, I have changed the way we run PHPUnit tests for extensions. * we now bring in mediawiki/vendor repository * mediawiki/core is now using the branch of the proposed patchset. So if you propose a patch for your extension against REL1_23, it will be tested with core@REL1_23. Previously we always used master. The job names have been changed: - 'mwext-{extension}-testextensions-master' + 'mwext-{extension}-testextension' Some jobs are still updating as I write this. Should be completed soon. If I see any failure in between I will retrigger the jobs. Something I have yet to figure out is to have the patch voted +2 to be tested sequentially to ensure the queue of proposed changes works well together. Should be dealt with this evening or at worse tomorrow. If anything is suspicious / failing. Please fill in bugs against Wikimedia > "Continuous integration". More details / doc will follow as time allow (see bug 1). -- Antoine "hashar" Musso

3 3

Oracle installation issue
by Bill Traynor 19 Sep '14

19 Sep '14

The installation fails with an ORA-00947 error due to not enough values in an INSERT statement. In the /maintenance/oracle/tables.sql code, I see this: CREATE SEQUENCE page_page_id_seq; CREATE TABLE &mw_prefix.page ( page_id NUMBER NOT NULL, page_namespace NUMBER DEFAULT 0 NOT NULL, page_title VARCHAR2(255) NOT NULL, page_restrictions VARCHAR2(255), page_counter NUMBER DEFAULT 0 NOT NULL, page_is_redirect CHAR(1) DEFAULT '0' NOT NULL, page_is_new CHAR(1) DEFAULT '0' NOT NULL, page_random NUMBER(15,14) NOT NULL, page_touched TIMESTAMP(6) WITH TIME ZONE, page_links_updated TIMESTAMP(6) WITH TIME ZONE, page_latest NUMBER DEFAULT 0 NOT NULL, -- FK? page_len NUMBER DEFAULT 0 NOT NULL, page_content_model VARCHAR2(32), page_lang VARCHAR2(35) DEFAULT NULL ); ALTER TABLE &mw_prefix.page ADD CONSTRAINT &mw_prefix.page_pk PRIMARY KEY (page_id); CREATE UNIQUE INDEX &mw_prefix.page_u01 ON &mw_prefix.page (page_namespace,page_title); CREATE INDEX &mw_prefix.page_i01 ON &mw_prefix.page (page_random); CREATE INDEX &mw_prefix.page_i02 ON &mw_prefix.page (page_len); CREATE INDEX &mw_prefix.page_i03 ON &mw_prefix.page (page_is_redirect, page_namespace, page_len); -- Create a dummy page to satisfy fk contraints especially with revisions INSERT INTO &mw_prefix.page VALUES (0, 0, ' ', NULL, 0, 0, 0, 0, current_timestamp, NULL, 0, 0, NULL); I see 14 columns defined, but only 13 values being passed. How can this ever work? I've already opened bug https://bugzilla.wikimedia.org/show_bug.cgi?id=71022 I'm not an Oracle person, so I'm not sure if this is normal or not. Thanks Bill

1 1

FOSS OPW: looking for female technical contributors
by Quim Gil 19 Sep '14

19 Sep '14

Dear wikimedians, The Free and Open Source Souftware Outreach Program for Women offers paid internships to developers and other technical profiles working on projects together with free software organizations. Wikimedia is participating again, and we welcome candidates. https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9 This call is open to Wikimedia volunteers (editors, developers...) and also to people that would contribute for the first time in our projects. In the past editions we have seen that candidates coming through a direct recommendation have good chances of success. It is also known that many good potential candidates will be reluctant to step in, but they will if someone (like you) encourages them to apply, or to contact us with any questions. You can make a difference. If you know women with software development or open source background / interest and full time availability between December and March, please forward them this invitation. Thank you! -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

3 4

AJAX mw.util.wikiscript with POST
by Toni Hermoso Pulido 19 Sep '14

19 Sep '14

Hello, for different custom extensions I've been doing something like this with GET: $.get( mw.util.wikiScript(), { format: 'json', action: 'ajax', rs: 'MyExt::MyFunction', rsargs: [param1, param2] }, function(data) { // console.log(data); }); MyExt::MyFunction is in $wgAjaxExportList[]. However, since now I have too much data for a URL (414 HTTP error) I'd prefer to use POST. So far I have not found a proper way to build it. Any idea or advice? Thanks! -- Toni Hermoso Pulido http://www.cau.cat http://www.similis.cc

4 5

apihighlimits and bot flags
by Jonas Öberg 19 Sep '14

19 Sep '14

Dear all, We're building a Firefox addon to perceptually match images in Commons against images found elsewhere, so that people can see that they come from Commons even if they appear on other web sites. https://moqups.com/jonaso/lopej41Z has a quick mockup. On https://commons.wikimedia.org/wiki/Commons:Bots/Requests/CommonsHasher we've requested the apihighlimits right (after discussion on commons-l starting here: https://lists.wikimedia.org/pipermail/commons-l/2014-September/007325.html) in order to be able to retrieve more than 50 records at once from the API. According to EugeneZelenko who tried to grant this right, it could not be granted through the normal interface. Question then: is apihighlimits included in the bot flag, or how can the apihighlimits right be granted? Sincerely, -- Jonas Öberg, Founder & Shuttleworth Foundation Fellow Commons Machinery | jonas(a)commonsmachinery.se E-mail is the fastest way to my attention

3 3

Fwd: [Wikimedia-l] Upcoming help sessions for drafting Individual Engagement Grant proposals
by Pine W 19 Sep '14

19 Sep '14

Forwarding. Please take this opportunity to ask questions! Pine ---------- Forwarded message ---------- From: "Siko Bouterse" <sbouterse(a)wikimedia.org> Date: Sep 18, 2014 3:30 PM Subject: [Wikimedia-l] Upcoming help sessions for drafting Individual Engagement Grant proposals To: <wikimedia-l(a)lists.wikimedia.org> Cc: Hi all, As we announced earlier this month[1], September is the month to apply for an Individual Engagement Grant[2]. The deadline to submit a proposal is September 30. To help you turn your ideas and projects into successful proposals, we’re hosting a few IdeaLab Proposal Clinics in Hangouts and IRC this month.[3] The first one took place on September 16. Newcomers had a chance to talk to current and past grantees, as well as WMF Grantmaking staff, to workshop ideas and strengthen their proposals. If you have an idea you would like to submit, but feel unsure about how to draft or finalize your proposal, join a session! There are three events left before the deadline: * IRC office hours in #wikimedia-office - Sept 23, 1600 UTC (Tuesday) * Hangout - Sept 25, 1700 UTC (Thursday) [4] * Hangout - Sept 28, 1700 UTC (Sunday) [5] Join us next week to discuss your ideas, and bring any questions you have about IEG! Cheers, Siko [1] https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074239.html [2] https://meta.wikimedia.org/wiki/Grants:IEG [3] https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events [4]IdeaLab Clinic II. Join via Hangout: https://plus.google.com/events/cvk8hivoih04ifc6pp3sl0se6s8?hl [5] IdeaLab Clinic III. Join via Hangout: https://plus.google.com/events/c82527nlv8jhkv17j963gs9gp6s?hl -- Siko Bouterse Head of Individual Grants Wikimedia Foundation, Inc. sbouterse(a)wikimedia.org *Imagine a world in which every single human being can freely share in the sum of all knowledge. * *Donate <https://donate.wikimedia.org> or click the "edit" button today, and help us make it a reality!* _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 0

RFC meeting next week
by Tim Starling 18 Sep '14

18 Sep '14

Next week's RFC meeting will discuss the following RFCs: * Extension management with Composer (Markus Glaser) <https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_wi…> * CentralNotice backend improvements (Tim Starling) <https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_backend_i…> It will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00 -- Tim Starling

1 0

[Release workflow recommendation] A public releases JSON file.
by Daniel Friesen 18 Sep '14

18 Sep '14

Every once in awhile I've found an idea for a service which would for one reason or another need to know what releases of MediaWiki exist and which ones are obsolete. As far as I know, we don't have any sort of API or machine readable metadata at all declaring this information for services to use. I'd like to see a change to the release workflow made that would support this use case. Some time ago I thought we should do this with an api, but now I think we can probably cover this by publishing a simple json file at either one of these urls: https://www.mediawiki.org/releases.json https://releases.wikimedia.org/mediawiki/releases.json The file will need to be updated every time a new release is made or an old one becomes obsolete. What does everyone and the release managers think? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

6 6

HTTPS on by default for logged out users: questions
by svetlana 17 Sep '14

17 Sep '14

In September 2013, HTTPS was enabled by default for logged in users. To my knowledge, in October 2014, it's planned to also enable it by default for logged out users. I asked some questions here. Please provide me with the missing information. https://meta.wikimedia.org/wiki/Talk:HTTPS#Preference

1 1

Status of collation config updates?
by Bartosz Dziewoński 17 Sep '14

17 Sep '14

Hi, There are currently three pending patches to change category collation configuration for various Wikimedia wikis: https://gerrit.wikimedia.org/r/140580 https://gerrit.wikimedia.org/r/147922 https://gerrit.wikimedia.org/r/154213 (This generally makes it so that accented letters like 'é' or 'ą' are not sorted at the end of lists, after 'z', and fixed ordering for languages with interesting alphabets; see https://www.mediawiki.org/wiki/Manual:$wgCategoryCollation.) I have previously been told that these are on hold because of WMF's Trusty migration and the need to rebuild all existing collation data. (No one told me how long that might take, but by my estimates that can't possibly take more than two or three weeks, and I know for a fact that it can be done with no downtime and minimal problems.) That was about two months ago. Is anything known about the current status of the collation things, and the Trusty migration in general? Is there any public venue that I could follow to know what is going on, or at least a private one I could be cc'd on if I asked pretty-please? Is there any ETA, even vague, as to when things might get done? I would like to update the bugs that are stuck with this information. -- Matma Rex

2 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l September 2014