Wikitech-l February 2016

wikitech-l@lists.wikimedia.org

103 participants
103 discussions

Medical leave
by Frances Hocutt 18 Feb '16

18 Feb '16

Dear all, I’m writing to give a heads-up that I expect to be taking medical leave from today through March 9, due in part to stress caused by the recent uncertainty and organizational departures. In my absence, my work will be in the capable hands of Ryan Kaldari and the rest of the Community Tech team. Any questions you would have directed to me, direct to Ryan. I hope to return as promptly as circumstance allows. All the best, Frances

6 5

(no subject)
by Josephine Lim 18 Feb '16

18 Feb '16

Hi all, I've been working on a project to improve the categorization of pictures in the Upload to Commons Android app <https://phabricator.wikimedia.org/T115101> as part of the Outreachy Dec '15 program, which is soon drawing to an end. To summarize, 3 new features have been implemented in this app: 1. If a picture with geolocation is uploaded, nearby category suggestions are offered (based on the categories of other Commons images with similar coordinates) 2. If a picture with no geolocation is uploaded, nearby category suggestions are offered based on the user's current location. This is optional and only works if enabled in Settings. 3. Category search (when typing in the search field) has been made more flexible, whereas previously this was done solely by prefix search. E.g. now searching for 'latte' should be able to return 'iced latte'. The latest version of the app is v1.11 and can be downloaded at <https://play.google.com/store/apps/details?id=fr.free.nrw.commons>. Please feel free to leave feedback or bug reports at <https://github.com/nicolas-raoul/apps-android-commons/issues>. I have had an amazing time working on this app as part of the Outreachy program, and I greatly appreciate all the support and help that the WMF community has given me. :) Cheers! -- Regards, Josephine

3 2

Phabricator Update
by Mukunda Modell 18 Feb '16

18 Feb '16

A significant update to https://phabricator.wikimedia.org is coming tonight! I will be taking Phabricator offline for a short time during the regularly scheduled maintenance window. This will take place between 01:00 - 03:00 UTC (5:00PM-7:00PM Pacific) There are a whole lot of new features and bug fixes coming with this update. Here are some of the most important bug fixes and requests for new functionality which can will resolved after the update: - T84833: When you close an unassigned task as "Resolved" from the Comment action, Phabricator thinks you want to claim the task <https://phabricator.wikimedia.org/T84833> - T89675: Phabricator avatars should have high definition version for HD displays <https://phabricator.wikimedia.org/T89675> - T119708: setting security to software security bug excluded subscribers <https://phabricator.wikimedia.org/T119708> - T89335: Creating private tasks by filling a web form (for AffCom) <https://phabricator.wikimedia.org/T89335> - T876: @mentions in descriptions should autocomplete <https://phabricator.wikimedia.org/T876> - T77228: Let non-members watch projects <https://phabricator.wikimedia.org/T77228> - T87135: Phabricator should only notify changes to the "Security" field if it is indeed changed <https://phabricator.wikimedia.org/T87135> - T120903: investigate hiding the policy controls for phabricator projects. <https://phabricator.wikimedia.org/T120903> - T91529: Turning the sprint flag on should apply the expected icon and color to the project <https://phabricator.wikimedia.org/T91529> - T115017: For new Phab accounts, link to [[mw:How to report a bug]] at the top of task creation form <https://phabricator.wikimedia.org/T115017> - T91538: Make new tasks within a specific project use a template in description field <https://phabricator.wikimedia.org/T91538> For context, there has been some ongoing discussion about potential issues at https://phabricator.wikimedia.org/conpherence/308/ - further documentation of the changes and their implications will be published soon. If you notice any serious issues after the update, please report them in phabricator or via IRC in the #wikimedia-devtools channel, however, please wait until the maintenance window is over before reporting any issues - problems encountered during the maintenance window are to be expected and reporting them will only serve as a distraction while the upgrade is underway. Thanks for your patience! Mukunda Modell Phabricator Release Engineer Wikimedia Foundation

1 0

2016-02-17 Scrum of Scrums meeting notes
by Grace Gellerman 17 Feb '16

17 Feb '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-02-17 = 2016-02-17 = == Technology == === Analytics === * '''*Blocking'''*: ** Discovery with a pageview API bug: T127034, Dan is working on it right now ** Multimedia with dumps parsing asks: T126808, T126809, Analytics will triage hopefully soon (within one or two weeks, but backlog is huge) * '''*Blocked'''* ** Services (known) because we need to refactor / move AQS (Analytics Query Service) out of the restbase repo * '''*Updates*'''*:* ** Same as last time, nothing new is ongoing - === Architecture === [No update.] === Performance === [No update.] === Release Engineering === * '''*Blocking'''*: ** Nothing new * '''*Blocked'''*: ** Looking for review on Phabricator ops/puppet role cleanup. See https://phabricator.wikimedia.org/T125851 ** Looking for a merge from Ops on scap3 provider changes. See https://phabricator.wikimedia.org/T127215 * '''*Updates*'''*:* ** See wmf.14 group1 deployment blockers https://phabricator.wikimedia.org/T125597 *** Save latency regression ** Progress on JS-based end-to-end (browser) tests in core. See https://gerrit.wikimedia.org/r/#/c/256404/ === Research === * '''*Blocking'''*: ** Nothing * '''*Blocked'''*: ** ORES still blocked on Ops. See https://phabricator.wikimedia.org/T106867 * '''*Updates*'''*:* ** Reader survey test went live 16 Feb in 16:00-17:00 PST SWAT time (5:100K sampling): for QA purposes ** Reader survey at full rate will go out 17 Feb 8:00-9:00 PST, for less than 2 weeks, at a 1:500 sampling rate: https://meta.wikimedia.org/wiki/Research:Characterizing_Wikipedia_Reader_Be… === Security === * '''*Blocking'''*: ** Nice to have: https://phabricator.wikimedia.org/T125382 (Maps) * '''*Blocked'''*: ** None. * '''*Updates*'''*:* ** 2FA for wikis progressing ** Security patches === Services === * '''*Blocking'''*: ** Nobody * '''*Blocked'''*: ** Separate AQS off of RESTBase - https://phabricator.wikimedia.org/T126294 *** need to schedule a time with Analytics Ops for the move ** Mathoid - SVG to PNG support *** librsvg(-dev) for Jessie * '''*Updates*'''*:* ** RESTBase: dropping listing URIs (/pagr/html/ , ...) ** Cassandra multi-instance work _still_ undergoing === Technical Operations === * '''*Blocking'''*: ** ORES moving into production, finally hardware is in place * '''*Blocked'''*: ** Nothing * '''*Updates*'''*:* ** Ongoing discussions/work about the switchover goal ** Moved with LE cxserver to jessie and node 4.2 == Product == === Community Tech === * '''*Blocking'''*: ** Nothing * '''*Blocked'''*: ** Gadgets 2.0 - blocked on ResourceLoader cache invalidation issue (Performance team) - https://gerrit.wikimedia.org/r/#/c/269901/ * '''*Updates*'''*:* ** PageAssessments === Discovery === ; '''*Blocking'''*: ** none ; '''*Blocked'''*: ** none ; '''*Updates*'''*:* ** Building more analytics about user satisfaction in completion ** TextCat merged, A/B tests to follow ** WDQS Blazegraph 2.0 work still in progress, getting there ** Discussing adding caching layer, for ops attention: https://phabricator.wikimedia.org/T126730 ** Discussing QuickSurvey with ops ==== Maps & Graphs ==== *; '''Updates'''* * Kartographer (maps) launched on beta cluster, getting ready to enable it on Wikivoyage ** VE has been helping, thanks Ed Sanders * Graphs can support WDQS, but might need caching (N.B. Operations) * Created a page-views graph - can be placed on a talk page to show corresponding view for the past N days. https://en.wikipedia.org/wiki/Template:Graph:PageViews *; '''Blockers'''* * Security: need SVG sanitization lib review (Security) - https://phabricator.wikimedia.org/T125382 ** Note that Performance were thinking of shipping sanitised user-provided SVGs to clients (instead of server-rendered PNGs), which would also need this functionality. *** Are we sanitizing SVG on upload/download? Or do we always convert them in a sanbox env to PNG? **** RIght now in production we always convert in a sandbox to PNG for normal page views, and (?) don't sanitise at all for download of the original SVG (on file pages). **** We sanitize on upload, mostly show PNG's in articles. Raw svg's are served from upload.wm.o (untrusted domain) === Editing === ==== Collaboration ==== * '''*Blocking'''*: ** Dry run patch for external store migration is merged. Now we need to set External Store up on Beta, then test the dry run patch there: https://phabricator.wikimedia.org/T119567 * '''*Blocked'''*: ** Flow dump generation on dumps.wikimedia.org: https://phabricator.wikimedia.org/T119511 * '''*Updates*'''*:* ** Human-readable name patch is almost done: https://phabricator.wikimedia.org/T121936 ** Will be enabling cross-wiki notifications on first set of wikis soon ( https://gerrit.wikimedia.org/r/#/c/265413/) ==== Language ==== * '''*Blocking'''*: ** Apertium packages? * '''*Blocked'''*: ** None. * '''*Updates*'''*:* ** cxserver migrated to Jessie with help of Alex ==== Multimedia ==== * '''*Blocking'''*: ** None * '''*Blocked'''*: ** Thumbor deployment blocks ImageTweaks deployment. Currently not a problem, as ImageTweaks is still rough. ** Security review of ImageTweaks pending, not currently ready to go, would like it to happen sometime this quarter ideally - more updates coming. https://phabricator.wikimedia.org/T126492 ** Illustration metrics "blocked" but not urgent. https://phabricator.wikimedia.org/T126809 https://phabricator.wikimedia.org/T126808 * '''*Updates*'''*:* ** Labs instance with ImageTweaks and Thumbor currently up and running, a bit of a demo as to what's coming to the cluster. See http://multimedia-alpha.wmflabs.org/wiki/index.php/Main_Page ** OOUI performance issues being worked on by MatmaRex, as part of UploadWizard performance improvements. ==== Parsing ==== * '''*Blocking'''*: ** None * '''*Blocked'''*: ** None * '''*Updates*'''*:* ** Work ongoing setting up mass visualdiff testing of rendering between 2 different mediawiki versions -- will appreciate help / feedback setting up mediawiki VMs (one per wiki) that closely reflects production config (extensions, skins, etc.). Currently considering vagrant, as well as manual setup (via scripts). ** Awaiting additional reviews / merge on the path to serialize HTML while using TemplateData settings (hopefully this week) -- first round of reviewing and edits done. ==== VisualEditor ==== * '''*Blocking'''*: ** None. * '''*Blocked'''*: ** Waiting on Design Research availability for user testing of Single Edit Tab integration * '''*Updates*'''*:* ** Will release the Single Edit Tab integration to a single wiki next Tuesday (huwiki) and assess impact ** Working with *Performance* on assessing the performance impact of OOUI on all read pages https://gerrit.wikimedia.org/r/#/c/271144/ – will update next week on results. ** Otherwise, we're working on performance issues, bugs, and language support, as normal. === Fundraising Tech === No blockers, most work is continued from last week * Implemented updates for new CiviCRM financial tracking, filling in the last missing pieces * fixes and enhancements for backup credit card processor * prep for Latin America fundraising expansion * beefing up fraud filters === Reading === ==== Android ==== * '''*Updates*'''*:* ** v2.1.141 published. Includes A/B test of readmore results. ==== Web ==== * '''*Updates*'''*:* ** Exploring surfacing references via API / lazy loading in web (see https://phabricator.wikimedia.org/T123328) - making headway ==== Reading Infrastructure ==== * Nothing of note this week.

1 0

Re: [Wikitech-l] [WikimediaMobile] Update on Upload to Commons Android App project
by Bahodir Mansurov 17 Feb '16

17 Feb '16

Thank you! I use regularly use this app and improvements are always welcome. On Wed, 17 Feb 2016 00:48:53 -0500, Josephine Lim <josephinelim86(a)gmail.com> wrote: > Hi all, > I've been working on a project to improve the categorization of > pictures in the Upload to Commons Android app > <https://phabricator.wikimedia.org/T115101> as part of the Outreachy > Dec '15 program, which is soon drawing to an end. To summarize, 3 new > features have been implemented in this app: > > 1. If a picture with geolocation is uploaded, nearby category > suggestions are offered (based on the categories of other Commons > images with similar coordinates) > > 2. If a picture with no geolocation is uploaded, nearby category > suggestions are offered based on the user's current location. This is > optional and only works if enabled in Settings. > > 3. Category search (when typing in the search field) has been made > more flexible, whereas previously this was done solely by prefix > search. E.g. now searching for 'latte' should be able to return 'iced > latte'. > > The latest version of the app is v1.11 and can be downloaded at > <https://play.google.com/store/apps/details?id=fr.free.nrw.commons>. > Please feel free to leave feedback or bug reports at > <https://github.com/nicolas-raoul/apps-android-commons/issues>. > > I have had an amazing time working on this app as part of the > Outreachy program, and I greatly appreciate all the support and help > that the WMF community has given me. :) > > > Cheers! > > -- Baha

1 0

Mass migration to new syntax - PRO or CON?
by Daniel Kinzler 17 Feb '16

17 Feb '16

Now that we target PHP 5.5, some people are itching to make use of some new language features, like the new array syntax, e.g. <https://gerrit.wikimedia.org/r/#/c/269745/>. Mass changes like this, or similar changes relating to coding style, tend to lead to controversy. I want to make sure we have a discussion about this here, to avoid having the argument over and over on any such patch. Please give a quick PRO or CON response as a basis for discussion. In essence, the discussion boils down to two conflicting positions: PRO: do mass migration to the new syntax, style, or whatever, as soon as possible. This way, the codebase is in a consistent form, and that form is the one we agreed is the best for readability. Doing changes like this is gratifying, because it's low hanging fruit: it's easy to do, and has large visible impact (well ok, visible in the source). CON: don't do mass migration to new syntax, only start using new styles and features when touching the respective bit of code anyway. The argument is here that touching many lines of code, even if it's just for whitespace changes, causes merge conflicts when doing backports and when rebasing patches. E.g. if we touch half the files in the codebase to change to the new array syntax, who is going to manually rebase the couple of hundred patches we have open? As can be seen on the proposed patch I linked, several of the long term developers oppose mass changes like this. A quick round of feedback in the architecture committee draws a similar picture. However, perhaps there are compelling arguments for doing the mass migration that we haven't heard yet. So please give a quick PRO or CON, optionally with some rationale. My personal vote is CON. No rebase hell please! Changing to the syntax doesn't buy us anything. -- daniel

21 29

MediaWiki-Codesniffer 0.6.0 released and [arrays, like, this]
by Legoktm 17 Feb '16

17 Feb '16

Hello! MediaWiki-Codesniffer 0.6.0 has been released, here's what's changed: * Add Generic.Arrays.DisallowLongArraySyntax to ruleset, autofix this repo (Kunal Mehta) * Add sniff to detect consecutive empty lines in a file (Vivek Ghaisas) * Disable Generic.Functions.CallTimePassByReference.NotAllowed (Kunal Mehta) * Update squizlabs/php_codesniffer to 2.5.1 (Paladox) Notably, this release now requires []-style arrays, as well as PHP 5.5.9 or higher to run. To help automatically migrate, you can use the "phpcbf" tool. I recommend setting up a "composer fix" command (for example [1]). Running just "composer fix" will try to auto-fix every file in the repo, while "composer fix filename" will just check that filename. [1] https://gerrit.wikimedia.org/r/#/c/271220/ Thanks, -- Legoktm

1 0

Update on Upload to Commons Android App project
by Josephine Lim 17 Feb '16

17 Feb '16

1 0

Fwd: [GSoC Mentors] GSoC Org Apps close soon
by James Salsman 17 Feb '16

17 Feb '16

If anyone has objections to Fabian, Maribel, and me continuing to mentor http://mediawiki.org/wiki/Accuracy_review under the GSoC program, please state your objections now. Quim, thank you for your kind words on the IEG application. ---------- Forwarded message ---------- From: *'sttaylor' via Google Summer of Code Mentors List* < google-summer-of-code-mentors-list(a)googlegroups.com> Date: Tuesday, February 16, 2016 Subject: [GSoC Mentors] GSoC Org Apps close soon To: Google Summer of Code Mentors List < google-summer-of-code-mentors-list(a)googlegroups.com> Just a quick reminder that the deadline to apply to be a GSoC 2016 mentor organization is this Friday, February 19th at 19:00 UTC. Visit our new website <https://g.co/gsoc> to apply as an organization today. For helpful tips on what is expected as a mentor organization and as a mentor or org admin for GSoC 2016 read the Mentor Manual <http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/>. We will not accept late applications under any circumstances. Good luck to all org applicants! Best, Stephanie -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com <javascript:_e(%7B%7D,'cvml','google-summer-of-code-mentors-list%2Bunsubscribe(a)googlegroups.com');> . To post to this group, send email to google-summer-of-code-mentors-list(a)googlegroups.com <javascript:_e(%7B%7D,'cvml','google-summer-of-code-mentors-list(a)googlegroups.com');> . Visit this group at https://groups.google.com/group/google-summer-of-code-mentors-list. For more options, visit https://groups.google.com/d/optout.

1 0

Jenkins: Composer require-dev packages now supported for MediaWiki builds
by Krinkle 17 Feb '16

17 Feb '16

Hi all, Over the weekend I worked on resolving https://phabricator.wikimedia.org/T112895 ("Support installing composer require-dev packages together with mediawiki/vendor"). With the help of Bryan Davis this has now been implemented and applied to all mediawiki core and extension jobs (mediawiki-*, mwext-*). Packages specified in mediawiki-core:/composer.json 'require-dev' section will now be fetched and installed in Jenkins, and the exposed interfaces are now available through the regular autoloader from Composer. Key points: * PHPUnit is now loaded from $WORKSPACE/vendor instead of the frozen legacy copy at /srv/deployment/integration/phpunit. * PHPUnit version has not yet changed (3.7.17). However upgrading is now as easy as changing a number in MediaWiki's composer.json. And such change will also be reflected in pre-merge test jobs, so that it can be verified before merging. – See https://phabricator.wikimedia.org/T99982 and https://gerrit.wikimedia.org/r/270485 * Aside from PHPUnit, one can now also other require-dev composer packages. For example, we may want to consider using something like vfsStream for file-system mocking in PHP. – https://phabricator.wikimedia.org/T86163 -- Krinkle

2 2

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

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 February 2016