Wikitech-l July 2016

wikitech-l@lists.wikimedia.org

81 participants
87 discussions

What's the "correct" content model when rev_content_model is NULL?
by Daniel Kinzler 15 Jul '16

15 Jul '16

It seems there is disagreement about what the correct interpretation of NULL in the rev_content_model column is. Should NULL there mean (a) "the current page content model, as recorded in page_content_model" or should it mean (b) "the default for this title, no matter what page_content_model says"? Kunal and I have had an unintentional edit war about this question in Revision.php: Kunal changed it from (a) to (b) in https://gerrit.wikimedia.org/r/#/c/222043/ I later changed it from (b) to (a) in https://gerrit.wikimedia.org/r/#/c/297787/ Kunal reverted me from (a) to (b) in https://gerrit.wikimedia.org/r/#/c/298239/ So, which way do we want it? The conflict seems to arise from (at least) three competing use cases: I) re-interpreting page content. For instance, a user may move a misnamed User:Foo.jss to User:Foo.js. In this case, the content should be re-interpreted as JavaScript, including all old revisions. This would be in favor of behavior (a), though it still works with (b), because the default model changes based on the suffix ".js". I think it would however be better to only rely on title parsing magic once, when creating the page, not later, when rendering old revisions. II) converting page content. For instance, if a talk page gets converted to using Flow, new revisions (and page_content_model) will have the Flow model, while old revisions need to keep their original wikitext model (even though their rev_content_model is null). That would need behavior (b). III) changing a namespace's default content model. E.g. when installing an extension that changes the default content model of a namespace (such as Wikibase with Items in the main namespace, or Flow-per-default for Talk pages), existing pages that were already in that namespace should still be readable. With (b), this would fail: even though page_content_model has the correct model for reading the page, rev_content_model is null, so the new namespace default is used, which will fail. With (a), this would simply work: the page will be rendered according to page_content_model. In all cases it's possible to resolve the issue by replacing the NULL entries for all revisions of a page with the current model id. The question is just when and how we do that, and when and how we can even detect that this needs doing. There is also an in-between option, let's call it a/b: fall back to page_content_model for the latest revision (that should *always* be right), but to ignore page_content_model for older revisions. That would cater to use case III at least in so far as it would be possible to view the "misplaced" pages. But viewing old revisions or diffs would still fail with a nasty error. This option may look better on the surface, but I fear it will just add to the confusion. There's another fix: never write null into rev_content_model. Always put the actual model ID there. That's pretty wasteful, but it's robust and reliable. When we decided to use null as a placeholder for the default, we assumed the default would never change. But as we now see, it sometimes does... So, what should it be, option (a) or (b)? And how do we address the use case that is then broken? What should we write into rev_content_model in the future? I personally think that option (a) makes more sense, because the resolutions of defaults is then local to the database. It could even be done within the SQL query. It's easier to maintain consistency that way. For use case II, that would require us to "fill in" all the rev_content_model fields in old revisions when converting a page. I think it would be a good thing to do that. If we have the content model change between revisions, it seems prudent to record it explicitly. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

9 24

Re: [Wikitech-l] phpunit: "Extension mysql is required"?
by Daniel Barrett 14 Jul '16

14 Jul '16

Never mind - solved it. I discovered that one of my phpunit test files contains @requires extension mysql and this extension is gone in PHP 7.0. DanB

2 1

2016-07-13 Scrum of Scrums meeting notes
by Grace Gellerman 14 Jul '16

14 Jul '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-07-13 = 2016-07-13 = == Product == === Reading === ==== Reading Infrastructure ==== * No update, but there will be a follow up meeting on Echo auth impl bug 20-July-2016 (multistakeholder bug) ==== Reading Web ==== * No update, working on language switcher on mobile web ==== iOS native app ==== * 5.0.5 is currently in beta - heading to regression on Tuesday * Setup new plan to incrementally improve regression testing * Development of 5.1 is in progress * Planning of 5.2 is in progress * Discovery implemented https://phabricator.wikimedia.org/T139378 to enable iOS to do https://phabricator.wikimedia.org/T130889 * Filed ticket to start work on a real time trending API: https://phabricator.wikimedia.org/T140102 ==== Android native app ==== ==== Mobile Content Service ==== * Getting close to having public endpoints for the random and aggregated feed endpoints. Removing blockers for that. * Service had been flapping quite a bit lately. Log files indicate heap memory issues. === Community Tech === * Investigating cross-wiki watchlist, how to implement back-end ** Refered to ArchComm as RFC * Will be deploying PageAssessments to English WIkipedia soon ( https://www.mediawiki.org/wiki/Extension:PageAssessments) * Also will be switching English Wikipedia to UCA collation with numerical sorting === Editing === ==== Collaboration ==== * Blocked: None * Blocking: No change * Update ** Finished rollout out bundling and re-sorting changes. Had a couple issues: *** We forgot to change Alerts/Messages to Alerts/Notices, so had to do a SWAT for this. This had complications initially: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160707-Echo *** We learned yesterday there was a bug in Echo that was causing users to have inconsistent state, which prevented login. This was fixed yesterday: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160712-EchoCen… ==== Multimedia ==== * Blocked: None? * Blocking: None? * Update: None? ==== Language ==== * Blocked: None? * Blocking: None? * Update: None? ==== Parsing ==== * Blocked: service-runner migration * Blocking: None? * Update: Services is helping with migrating Parsoid to the service-runner framework. Parsoid deployments are on hold till that time. Migration to node v4, jessie, scap3 will follow that migration. ==== VisualEditor ==== * Blocked: None. * Blocking: None known. * Update: Lots of work on bugs and regressions this week; https://gerrit.wikimedia.org/r/#/c/298392/ / T129360 in MobileFrontend is the remaining focus. == Technology == === Services === '''Blocking''' ** None '''Blocked''' ** None * Node security upgrade: RB, AQS and SCB on Nodejs 4.4.6, Parsoid pending move to Jessie * RESTBase Cassandra cluster upgraded to 2.2.6 * Preparing deploy of new feed API end points (ex: featured article / image) with Reading. ETA likely this week. * Parsoid move to service-runner - *https://phabricator.wikimedia.org/T90668* <https://phabricator.wikimedia.org/T90668> ** Currently testing in BetaCluster **Ping for Ops: need to coordinate the transition in prod === Fundraising Tech === * Civi upgrade complete * CentralNotice deployed * Upgrading payments to MW 1.26 * Building out new servers * Kafka sampling problem solved * No blockers === TechOps === '''Blocking''' ** None * '''Blocked''' ** https://phabricator.wikimedia.org/T135483 - HHVM crashes - raised to UBN! after issue recurrence. Currently no one owns the ticket. * Updates ** About 25% of the MediaWiki clusters run on jessie, we will start reimaging old servers during this quarter, a schedule will be announced. ** Enabled TCP Fast Open on some caching clusters ** Insecure POST traffic cutoff: All external traffic is prohibited, but labs is still permitted (with a 20% failure rate) === Security === * Node.js dependencies are now being checked nightly for disclosed vulnerabilities; Darian will be manually creating Phab tickets about this initially, with automation to follow * Request security reviews: https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Security_reviews * A security release will be prepared soon, possibly July 20 * Reviews: Tool Labs Console (cont.) ===Wikidata / WMDE=== * Daniel is working on multi-content revisions https://phabricator.wikimedia.org/T107595 * Continuing work on structured data support for commons * Preparing deploy of RevisionSlider to test wikis and then as a beta feature on German Wikipedia https://phabricator.wikimedia.org/T140232 === Discovery === * '''Blocking''': none * '''Blocked''': none * Logstash upgrade postponed to Jul 18th, 19-22 UTC * Initiated discussion on using ? in searches: https://meta.wikimedia.org/wiki/Discovery/Handling_question_marks_in_search… * Geosearch (near*:) is ready to roll out in production: https://phabricator.wikimedia.org/T139378 in 1.28.0-wmf.10 * Started discussion on new wikipedia.org portal layout: https://www.mediawiki.org/wiki/Wikipedia.org_updated_page_layout * Geoshapes in graphs and (soon) maps: http://data.wmflabs.org/wiki/Regional_maps === RelEng === * '''Blocking''' ** None * '''Bocked''' ** None * '''Updates''' ** New gerrit update needs testing: https://gerrit-new.wikimedia.org/r/ <https://gerrit-new.wikimedia.org/r/> ** wmf.9 was reverted, wmf.10 will get pushed to group0 and group1 today on a short schedule *** Retrospective to come https://wikitech.wikimedia.org/wiki/Incident_documentation/20160712-EchoCen… === Architecture === * ArchCom weekly meetings today: ** 1pm PDT Planning meeting (private): [[Phab:E227]] ** 2pm PDT Discussion (public) IRC #wikimedia-office: [[Phab:E228]] *** Topic: [[Phab:T589]] - image and oldimage tables * Anything stalled? Comment in Phab here: [[Phab:Z425]]

1 0

phpunit: "Extension mysql is required"?
by Daniel Barrett 13 Jul '16

13 Jul '16

[Tried mediawiki-l, now trying wikitech-l] What does it mean when I run MediaWiki unit tests on my server, and phpunit skips some tests with this error: Extension mysql is required This is on a fully working MediaWiki server with mySQL installed, running on Ubuntu 16.04. $ mysql --version mysql Ver 14.14 Distrib 5.7.12, for Linux (x86_64) using EditLine wrapper $ dpkg -s php-mysql Package: php-mysql Status: install ok installed ... Thank you, DanB

1 0

Change to SWAT deploy (aka "let's not break things")
by Greg Grossmeier 13 Jul '16

13 Jul '16

Hello! For a while we've had the ability to test changes in production on a single host (mw1017) using a special HTTP header (X-Wikimedia-Debug). This has proved useful for many when deploying changes in production and we are adding it to the SWAT deploy process. See the steps at: https://wikitech.wikimedia.org/wiki/SWAT_deploys#Doing_the_deploy Namely: 4. After merge, the SWAT team member fetches the patch(es) to tin and then runs scap pull on mw1017 5. The submitter tests the change by using the instructions at X-Wikimedia-Debug#Staging_changes AND the SWAT team member checks the error logs 6. If there are no errors and the fix seems to work (if testable in that manner), then then SWAT team member deploys the patch to the entire fleet How to test on mw1017: https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug#Staging_changes To less exciting SWAT deploys, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

2 1

How to fake a login with AuthManager?
by Daniel Barrett 13 Jul '16

13 Jul '16

What is the proper incantation for faking a successful login (for a given user) as part of a unit test? My old code was: $context = RequestContext::getMain(); $specialPage = new LoginForm( $context->getRequest() ); $user->logout(); $specialPage->showReturnToPage('successredirect'); $specialPage->successfulLogin(); What is the right way to perform this task with AuthManager? Thanks very much, DanB

2 2

Revert to 1.28.0-wmf.8
by Matthew Flaschen 12 Jul '16

12 Jul '16

All wikis were rolled back to 1.28.0-wmf.8 last night due to an increase in https://phabricator.wikimedia.org/T119736 . We're working on it, and will either go back to 1.28.0-wmf.9, or to 1.28.0-wmf.10 (at normal train pace) when it's resolved. Matt

1 0

2016W28 ArchCom-RFC meeting: image and oldimage tables
by Rob Lanphier 12 Jul '16

12 Jul '16

Hi all, The ArchCom-RFC office hour is coming up soon (Wednesday, 21:00 UTC, 2pm PDT, 23:00 CEST). Our topic: image and oldimage tables (which are an artifact from when we had "cur" and "old" tables). Rumor has it that it was discussed at the 2011 Amsterdam Hackathon Phab task: https://phabricator.wikimedia.org/T589 Phab event: https://phabricator.wikimedia.org/E228 Phab phour: https://en.wikipedia.org/wiki/Fab_Four The ArchCom status page continues to have regular updates from the group: https://www.mediawiki.org/wiki/Architecture_committee/Status Rob

1 0

Weigh in on whether to finalize "Cases" section of CoC
by Matthew Flaschen 12 Jul '16

12 Jul '16

Please comment on whether to approve the "Cases" section of the draft Code of conduct for technical spaces (https://www.mediawiki.org/wiki/Code_of_Conduct/Draft#Page:_Code_of_Conduct.…). You can comment at https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_.22Cases… . A position and brief comment is fine. You can also send private feedback to conduct-discussion(a)wikimedia.org . Thanks again, Matt Flaschen

1 0

BREAKING CHANGE, ACTION NEEDED: Flow Vagrant role split into 2
by Matthew Flaschen 12 Jul '16

12 Jul '16

I've split the Flow MediaWiki-Vagrant role into two, to make things simpler for casual Flow users. If you don't have the Flow role enabled, you can stop reading now. The basic 'flow' role will no longer depend on External Store and other optional dependencies. You now need to do one of these things: --- TLDR: If you use Flow on Vagrant regularly, enable wikimediaflow. Otherwise, enable externalstore or destroy your Vagrant. --- * Enable 'wikimediaflow' (if you care about existing Flow content). This will bring in the optional dependencies again, and leave your content as-is. * Enable 'externalstore' (if you care about existing non-Flow content that is using External Store already). Avoids the other optional dependencies, but brings in External Store, so existing External Store content can be read. * Manually tweak configuration * Just ignore the problems with old content * Destroy and re-create your Vagrant (this will destroy the invalid content that points to no-longer-existing External Store, and leave you with a simpler config). Matt

1 0

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

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