[Wikidata-bugs] [Maniphest] [Commented On] T142986: [Task] check for and fix breakage we introduced in Primary Sources Tool with recent refactoring
Sjoerddebruin added a comment. I've got a different one on another item: TypeError: null is not an object (evaluating 'listitem.startEditing')TASK DETAILhttps://phabricator.wikimedia.org/T142986EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SjoerddebruinCc: Sjoerddebruin, Jan_Dittrich, Aklapper, thiemowmde, Jonas, Lydia_Pintscher, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142986: [Task] check for and fix breakage we introduced in Primary Sources Tool with recent refactoring
Sjoerddebruin added a comment. In T142986#2563601, @Sjoerddebruin wrote: In T142986#2563600, @Jonas wrote: @Sjoerddebruin this looks more like a backend problem of the PS tool. Do you have a console log? Nope, will send you one if I'll encounter it again. This is showing up there: [Warning] This page is using the deprecated ResourceLoader module "jquery.ui.widget". [Warning] This page is using the deprecated ResourceLoader module "jquery.effects.core". [Warning] This page is using the deprecated ResourceLoader module "jquery.jStorage". Please use "mediawiki.storage" instead. [Warning] This page is using the deprecated ResourceLoader module "jquery.tipsy". [Warning] This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead. Not sure if it applies to the primary sources tool, though.TASK DETAILhttps://phabricator.wikimedia.org/T142986EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SjoerddebruinCc: Sjoerddebruin, Jan_Dittrich, Aklapper, thiemowmde, Jonas, Lydia_Pintscher, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T121978: Label of Wikidata item is not changed by rename of the source article
SJu added a comment. The differences between Wiidata labels and linked pages from other projects should be tracked and listed for review. The lists should be special forms (by language) with clickable service buttons, e.g. "correct the label", "approve the distinction", "suggest for discussion" etc. Handling capitals should be included. Typical cases of acceptable distinctions should be analyzed and described (e.g. synonymic titles, language variations etc.).TASK DETAILhttps://phabricator.wikimedia.org/T121978EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SJuCc: Nikki, Sjoerddebruin, hoo, Aklapper, SJu, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T142491: Make ContentHandler search fields reusable across content models
Smalyshev closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T142491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: gerritbot, debt, Smalyshev, Aklapper, aude, mschwarzer, Avner, Gehel, D3r1ck01, FloNight, Izno, Wikidata-bugs, Deskana, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T142491: Make ContentHandler search fields reusable across content models
ReleaseTaggerBot added projects: MW-1.28-release-notes, WMF-deploy-2016-08-23_(1.28.0-wmf.16). TASK DETAILhttps://phabricator.wikimedia.org/T142491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, ReleaseTaggerBotCc: gerritbot, debt, Smalyshev, Aklapper, aude, mschwarzer, Avner, Gehel, D3r1ck01, FloNight, Izno, Wikidata-bugs, Deskana, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T134723: Project Weekly Reports for Automated Testing and Integration of IFTTT support to Wikidata
D3r1ck01 edited the task description. (Show Details) EDIT DETAILS...* Combination of all my work in GSoC from the first day can be seen here (a list of all the commits): [[https://github.com/wikimedia/ifttt/commits/gsoc?author=ch3nkula | All commits]]author=ch3nkula | All commits]] * Migration of the IFTTT application on Wikimedia Tool Labs from Grid Engine to Kebernetes. This was the suggestion from Stephen (primary mentor) and it sounded good and more over why not use recent tool labs technology. So the application now runs on Kebernetes.TASK DETAILhttps://phabricator.wikimedia.org/T134723EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: D3r1ck01Cc: Zppix, Bene, Samtar, hoo, Lydia_Pintscher, Slaporte, Aklapper, Sumit, D3r1ck01, Lethexie, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142491: Make ContentHandler search fields reusable across content models
gerritbot added a comment. Change 303838 merged by jenkins-bot: Extract ParserOutput search index data fields from WikiTextContentHandler https://gerrit.wikimedia.org/r/303838TASK DETAILhttps://phabricator.wikimedia.org/T142491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, gerritbotCc: gerritbot, debt, Smalyshev, Aklapper, aude, mschwarzer, Avner, Gehel, D3r1ck01, FloNight, Izno, Wikidata-bugs, Deskana, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
Anomie added a comment. Yeah, it looks like you're right. Strike most of the ones about broken infrastructure. But I still haven't seen this on Scribunto extension tests ever.TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, AnomieCc: greg, gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T137933: Article placeholder has wrong link in "other languages" box in sidebar
hoo closed this task as "Resolved".hoo removed a project: Patch-For-Review. TASK DETAILhttps://phabricator.wikimedia.org/T137933EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: gerritbot, Lucie, Aklapper, jeblad, Zppix, D3r1ck01, Izno, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T137933: Article placeholder has wrong link in "other languages" box in sidebar
gerritbot added a comment. Change 302266 merged by jenkins-bot: Fix the links displayed in other languages sidebar https://gerrit.wikimedia.org/r/302266TASK DETAILhttps://phabricator.wikimedia.org/T137933EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Lucie, Aklapper, jeblad, Zppix, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
Anomie added a comment.
In T143389#2568039, @greg wrote:
@Anomie: can you help me understand what this test is trying to test for and what it means that it is now failing (iow: a failing test should imply broken code: where's the broken code?).
Scribunto has a feature where it limits the total CPU time used to a configurable limit, to prevent a module from running indefinitely during the parse.
Some things that nominally occur "inside" Lua really should not be counted against this time limit. For example, the wikitext {{#invoke:MyModule|myFunc| {{some template}} }} calls the function myFunc in Module:MyModule, passing as a parameter the expanded wikitext of {{some template}}. For performance, however, MediaWiki does not actually expand the wikitext for {{some template}} until it's actually accessed inside MyModule. Per T47684: getExpandedArguments should not count toward the 10-second Lua execution limit, this argument expansion time should not be counted against the time limit. On the other hand, if something inside MyModule parses wikitext instead of having it passed in as an argument, the time inside that recursive parse should count against the time limit.
This test verifies that the time is accounted as described above, i.e. that Scribunto calls luasandbox's pauseUsageTimer() and unpauseUsageTimer() in the right places to get the proper outcome. It does that by constructing a simple version of {{some template}} that is intended to reliably use 0.500s of CPU time, then asks Scribunto how much CPU time was actually measured. In the cases where the argument expansion time should not be counted, Scribunto should have only accounted somewhere around 0.001s. The test itself checks whether accounted time is more or less than 0.250s.
This task is about the fact that something in WMDE's CI infrastructure is causing Scribunto to measure accounted time far in excess of 0.001s during this test. I can think of a few possibilities, but nothing that gives me something to do about it:
luasandbox appears to count both 'user' and 'system' time, while the test only checks 'user' time when implementing the delay. But that shouldn't cause the test to fail: it would make the delay longer than 0.5s of total CPU time, but that shouldn't matter when it's not supposed to be counted and the cases where it is counted aren't the problem here.
There might be a bug in luasandbox that makes it count time incorrectly. As far as I know, though, we've never run into this on WMF's CI infrastructure and I've never seen it in local testing, so I have no way to begin reproducing it to test this hypothesis.
WMDE's CI infrastructure might be using a version of luasandbox compiled without the presence of the CLOCK_THREAD_CPUTIME_ID constant for clock_gettime(), in which case it would measure wall time rather than CPU time. I have no way to check this.
WMDE's virtualized CI infrastructure might be emulating a system with a variable clock speed, so sometimes instead of a 2GHz processor it's running a 2KHz processor. That could cause even parts of the code that normally take only 0.001s to take radically more time than that due to the excessively slow processor. I have no way to test this.
WMDE's virtualized CI infrastructure might have buggy POSIX clock or timer behavior in the virtualized environment that somehow breaks luasandbox's accounting. For example, it might implement CLOCK_THREAD_CPUTIME_ID in terms of wall clock time or host CPU time instead of virtualized environment CPU time. I have no way to test this either.
WMDE's virtualized CI infrastructure might have bugs that cause it to randomly block for relatively long periods of time in system calls in a way that still counts as system time used. I have no way to test this either.
Something involved in one of their extensions being tested in conjunction with Scribunto might be causing extreme slowdowns in parts of the code outside the bit that's specifically not accounted. It seems unlikely that they wouldn't have noticed this themselves, and I wouldn't know where to begin to even start with testing that theory.
TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, AnomieCc: greg, gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Merged] T143263: Merge.js: purge items after merging without confirmation
hoo added subscribers: Multichill, Legoktm, aaron.hoo merged a task: T143435: Purge asks for "Clear the cache of this page" for logged in users with the "purge" right. TASK DETAILhttps://phabricator.wikimedia.org/T143263EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: aaron, Legoktm, Multichill, hoo, Edgars2007, Sjoerddebruin, Aklapper, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T143263: Merge.js: purge items after merging without confirmation
hoo closed this task as "Resolved".hoo claimed this task.hoo added a comment. Fixed with https://www.wikidata.org/w/index.php?diff=366782385=360660535TASK DETAILhttps://phabricator.wikimedia.org/T143263EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: hoo, Edgars2007, Sjoerddebruin, Aklapper, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
greg added a comment. In T143389#2567454, @gerritbot wrote: Change 305649 had a related patch set uploaded (by Hoo man): Make Scribunto_LuaSandboxTests::testArgumentParsingTime more robust https://gerrit.wikimedia.org/r/305649 It looks like this patch is moving forward nicely in a productive working relationship way. Thank you @hoo, for providing that.TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, gregCc: greg, gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Lowered Priority] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
greg lowered the priority of this task from "Unbreak Now!" to "High".greg added a comment. I understand your frustration but two things: This is not UBN!, it is High, as you/the scribunto maintainer have been dealing with this for a while now. This is just semantics. Please be more diplomatic when communicating with your co-workers. Words like "bogus", "time waster", "ridiculous" in the commit messages do not add any real value and instead only incite the other party. @Anomie: can you help me understand what this test is trying to test for and what it means that it is now failing (iow: a failing test should imply broken code: where's the broken code?).TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, gregCc: greg, gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T142944: Performance and caching considerations for article placeholders accesses
hoo added a subtask: T117693: [Story] ArticlePlaceholder pages should show up in search engines. TASK DETAILhttps://phabricator.wikimedia.org/T142944EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: DaBPunkt, BBlack, daniel, Lydia_Pintscher, Joe, Lucie, Aklapper, hoo, D3r1ck01, Izno, Wikidata-bugs, aude, jayvdb, Ricordisamoa, faidon, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T117693: [Story] ArticlePlaceholder pages should show up in search engines
hoo added a parent task: T142944: Performance and caching considerations for article placeholders accesses. TASK DETAILhttps://phabricator.wikimedia.org/T117693EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucie, hooCc: MZMcBride, DarTar, Nemo_bis, Ricordisamoa, Lucie, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, jayvdb, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI)
Izno added a comment. I'm sitting here puzzled, because nothing in the rationale indicates to me that this can't already be done using existing datatypes (item) and properties (birth name, perhaps a new 'full name' parameter in case someone wants to be attributed as something other than their birth name). Are we trying to avoid introducing 'non-notable' individuals to the database? Is that all we're working around here?TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: IznoCc: thiemowmde, Ladsgroup, Liuxinyu970226, Pigsonthewing, Bugreporter, Jan_Dittrich, Josve05a, Sadads, Pokefan95, gerritbot, DannyH, Micru, intracer, mkroetzsch, Aklapper, daniel, Steinsplitter, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143424: [Task] Explore the Entity Relevancy Scoring for Wikidata
Sjoerddebruin added a comment. The number of incoming links to a item could be a indication of relevancy, but probably the most difficult one to add.TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SjoerddebruinCc: Sjoerddebruin, Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T143424: [Task] Explore the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus edited the task description. (Show Details) EDIT DETAILS...The purpose of this is, to allow the users to find their desired items more easily. Currently, we are taking into account the number of sitelinks and labels. We should see if this is still sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T143424: [Task] Explore the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus edited the task description. (Show Details) EDIT DETAILSWikidata has a lot of items with the same label. We should explore ways to rank them according to their relevance. For example, Berlin (the capital of Germany) should be ranked higher than Berlin (the album) in suggestions.! The purpose of this is, to allow the users to find their desired items more easily. Currently, we are taking into account the number of sitelinks and labels. We should see if this is still sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T143424: [Task] Explore the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus edited the task description. (Show Details) EDIT DETAILSWikidata has a lot of items with the same label. We should explore ways to rank them according to their relevance. For example, Berlin (the capital of Germany) should be ranked higher than Berlin (the album) in suggestions..! The purpose of this is, to allow the users to find their desired items more easily. Currently, we are taking into account the number of sitelinks and labels. We should see if this is still sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T143423: Change Wikibase entity access parser limit report
gerritbot added a project: Patch-For-Review. TASK DETAILhttps://phabricator.wikimedia.org/T143423EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, gerritbotCc: gerritbot, Aklapper, daniel, aaron, thiemowmde, aude, hoo, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T143424: [Task] Explore the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus changed the title from "[Task] Exploring the Entity Relevancy Scoring for Wikidata" to "[Task] Explore the Entity Relevancy Scoring for Wikidata".Glorian_Yapinus edited the task description. (Show Details) EDIT DETAILSWe need to explore entity relevancy scoring for Wikidata. Wikidata has a lot of items with the same label. We should explore ways to rank them according to their relevance. For example, Berlin (the capital of Germany) should be ranked higher than Berlin (the album) in suggestionsTASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T143424: [Task] Explore the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus edited the task description. (Show Details) EDIT DETAILSWikidata has a lot of items with the same label. We should explore ways to rank them according to their relevance. For example, Berlin (the capital of Germany) should be ranked higher than Berlin (the album) in suggestions.. The purpose of this is, to allow the users to find their desired items more easily. Currently, we are taking into account the number of sitelinks and labels. We should see if this is still sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143423: Change Wikibase entity access parser limit report
gerritbot added a comment. Change 305655 had a related patch set uploaded (by Hoo man): Change entity access parser limit report https://gerrit.wikimedia.org/r/305655TASK DETAILhttps://phabricator.wikimedia.org/T143423EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, gerritbotCc: gerritbot, Aklapper, daniel, aaron, thiemowmde, aude, hoo, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T143424: [Task] Exploring the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus added a parent task: T90870: selfcontained projects around Wikidata (tracking). TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T90870: selfcontained projects around Wikidata (tracking)
Glorian_Yapinus added a subtask: T143424: [Task] Exploring the Entity Relevancy Scoring for Wikidata. TASK DETAILhttps://phabricator.wikimedia.org/T90870EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: T.seppelt, Ricordisamoa, mkroetzsch, Aklapper, Lydia_Pintscher, mschwarzer, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T143424: [Task] Exploring the Entity Relevancy Scoring for Wikidata
Glorian_Yapinus created this task.Glorian_Yapinus added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWe need to explore entity relevancy scoring for Wikidata. Wikidata has a lot of items with the same label. We should explore ways to rank them according to their relevance. For example, Berlin (the capital of Germany) should be ranked higher than Berlin (the album) in suggestions. The purpose of this is, to allow the users to find their desired items more easily. Currently, we are taking into account the number of sitelinks and labels. We should see if this is still sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T143424EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_YapinusCc: Glorian_Yapinus, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T143423: Change Wikibase entity access parser limit report
hoo created this task.hoo added projects: MediaWiki-extensions-WikibaseClient, Wikidata, Wikidata-Sprint-2016-08-16. TASK DESCRIPTIONChange it as laid out in T142713: Standardize Wikibase client parser limit report.TASK DETAILhttps://phabricator.wikimedia.org/T143423EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Aklapper, daniel, aaron, thiemowmde, aude, hoo, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Block] T142713: Standardize Wikibase client parser limit report
hoo created subtask T143423: Change Wikibase entity access parser limit report. TASK DETAILhttps://phabricator.wikimedia.org/T142713EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: aude, thiemowmde, aaron, daniel, Aklapper, hoo, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T142713: Standardize Wikibase client parser limit report
hoo closed this task as "Resolved".hoo claimed this task.hoo added a comment.
Given that I received no input here, I chose to go with the following, because that seems to be consistent with other limits:
"limitreportdata": [
{
"name": "limitreport",
"cputime": "0.137",
"walltime": "0.752",
…
"expensivefunctioncount": {
"value": 2,
"limit": 500
},
"entityaccesscount": {
"value": 2,
"limit": 250
},
…
]TASK DETAILhttps://phabricator.wikimedia.org/T142713EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: aude, thiemowmde, aaron, daniel, Aklapper, hoo, D3r1ck01, Izno, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T142107: Update documentation for Wikibase notifications on mediawiki.org
Trizek-WMF changed the title from "Update documentation on mediawiki.org" to "Update documentation for Wikibase notifications on mediawiki.org". TASK DETAILhttps://phabricator.wikimedia.org/T142107EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanek, Trizek-WMFCc: Trizek-WMF, Aklapper, Lydia_Pintscher, matej_suchanek, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, Spage___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142107: Update documentation on mediawiki.org
Trizek-WMF added a comment. I've removed the screenshot. Would it be possible to have a more real case than ont done by a local IP?TASK DETAILhttps://phabricator.wikimedia.org/T142107EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanek, Trizek-WMFCc: Trizek-WMF, Aklapper, Lydia_Pintscher, matej_suchanek, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, Spage___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T138365: [Discuss-Storytime][Usability] Error message should help to solve problem when assigning a non well formed URL as value to an URL-restricted property resu
Jonas closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T138365EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: gerritbot, daniel, Lydia_Pintscher, Aklapper, Zppix, Charlie_WMDE, Jonas, thiemowmde, Jan_Dittrich, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T142694: [Story] Refactor Add-/Remove-Toolbar
Jonas edited the task description. (Show Details) EDIT DETAILS...[x] Introduce StructureEditorFactory https://gerrit.wikimedia.org/r/#/c/298755/ [ [x] Add getReferenceView https://gerrit.wikimedia.org/r/#/c/298757/...TASK DETAILhttps://phabricator.wikimedia.org/T142694EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: thiemowmde, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T142694: [Story] Refactor Add-/Remove-Toolbar
Jonas edited the task description. (Show Details) EDIT DETAILS...[x] Clean up EditableTemplatedWidget and implementations https://gerrit.wikimedia.org/r/#/c/298754/ [ [x] Introduce StructureEditorFactory https://gerrit.wikimedia.org/r/#/c/298755/...TASK DETAILhttps://phabricator.wikimedia.org/T142694EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: thiemowmde, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T140760: [Task] Create mediainfo entity on demand when adding a statement the first time
hoo added a comment. In T140760#2567482, @thiemowmde wrote: I believe this is done, but have not confirmed. The second bullet point from the task description is still open, isn't it?TASK DETAILhttps://phabricator.wikimedia.org/T140760EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, hooCc: hoo, Lydia_Pintscher, Jonas, thiemowmde, daniel, Aklapper, Tobi_WMDE_SW, Zppix, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T140760: [Task] Create mediainfo entity on demand when adding a statement the first time
thiemowmde added a comment. I believe this is done, but have not confirmed.TASK DETAILhttps://phabricator.wikimedia.org/T140760EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, thiemowmdeCc: Lydia_Pintscher, Jonas, thiemowmde, daniel, Aklapper, Tobi_WMDE_SW, Zppix, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
gerritbot added a comment. Change 305649 had a related patch set uploaded (by Hoo man): Make Scribunto_LuaSandboxTests::testArgumentParsingTime more robust https://gerrit.wikimedia.org/r/305649TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, gerritbotCc: gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI)
daniel added a comment. Here's a straw man idea for the approach using qualifiers: Scenario: we assume that we typically have the plain text name, and use it to find a URI, not the other way around we have a "person" data type that uses plain string values we have a single well known property for qualifying a "person"-type statement with a URL/URI that identifies the person. This means: The new data type can be added with minimal effort in the backend. Clients that need to know a URI for a person need to know about the person-uri qualifier property The UI needs to know the special qualifier property. UI integration could work like this: if the statement has the type "person" and does not yet have a person-uri qualifier, a button labeled "Find URI for Foo" is added next to the "add qualifier" button. "Foo" is the plain name from the main snak. when that button is clicked, we search well known data sets (Wikimedia users, Wikidata items, ORCID, VIAF) for the name, and allow the user to choose one of the results. a person-uri qualifier is added containing the URI from the search. When editing a "person" statement that already has a person-uri qualifier, nothing special happens. @Lydia_Pintscher, @Jan_Dittrich, what do you think? It seems to me that the decision is mostly a UI issue at this point.TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: thiemowmde, Ladsgroup, Liuxinyu970226, Pigsonthewing, Bugreporter, Jan_Dittrich, Josve05a, Sadads, Pokefan95, gerritbot, DannyH, Micru, intracer, mkroetzsch, Aklapper, daniel, Steinsplitter, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI)
daniel added a comment. The central idea is: We want to be able to use the same property for all the different ways we may want to use to identify a person. During our last discussion it turned out that the primary information we need to include is a plain text name, to cover the legal requirements of some (most?) licenses. The URI/URL should be optional, but we want a UI that makes it easy to add one at least for the common cases (Wikimedia user, Wikidata item, ORCID, VIAF, etc), to provide a nice editing interface. The user interface should make entry easy: after entering a name, the user should be able to search for that name in some well known places (Wikimedia user, Wikidata item, ORCID, VIAF, etc) to determine the URI, or enter the URI directly. When entering a URI directly, we may want the UI to detect well known prefixes of URIs for Wikimedia user, Wikidata item, ORCID, VIAF, etc. The simplest approach would be to use a plain string value to represent the name, and a qualifier for the URI. We could even use different properties (with data type URL or external ID) for qualifiers that represent the different kinds of IDs. However, this has two major disadvantages: Clients will have to know about the "special" qualifiers in order to determine the URI for the person in question. To allow nice and editing entry of both the name and the URL/URI, the UI would need to closely integrate the editing of the main value with editing a qualifier. It's unclear to me how to do this in a way that does not interfere with the "generic" way to edit qualifiers, causing confusion. The alternative is to introduce a new value type containing a plain text name and an optional URI. This adds complexity to the data model, but avoids the need for "arcane" knowledge in the UI and in clients. It also avoids special case magic in the UI for handing statements that have some special qualifiers.TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: thiemowmde, Ladsgroup, Liuxinyu970226, Pigsonthewing, Bugreporter, Jan_Dittrich, Josve05a, Sadads, Pokefan95, gerritbot, DannyH, Micru, intracer, mkroetzsch, Aklapper, daniel, Steinsplitter, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T127929: [Story] Add a new datatype for linking to creators of artwork and more (smart URI)
daniel edited the task description. (Show Details) EDIT DETAILS...* a person represented by an item on Wikidata The person needs to be identified by a plain text name, to satisfy legal requirements. In addition, a URL (resp URI) can be given to uniquely identify the person (or legal entity). So we need a new Wikibase datatype that covers them all so statements can be made using the same property. Our current thinking: This would be a new datatype representing a smart URI - internally it'd always be a URIOur current thinking: This would be a new datatype representing a plain text name and an optional URI. The user interface should be "smart" about well known types of URLs - for example, it could have a selector that offers Commons user pages, Flickr user pages and a bunch of others as a drop-down. Whether the URL would be part of the main data value, or whether it should be provided as a qualifier, is not yet decided. andIf we add nice UI handling for a small number of special cases.use qualifiers, For example it could have a selector that offers Commons user pages,a more complex widget is needed that allows the main value and the relevant qualifier to be edited together. Flickr user pages and a bunch of others as a drop-down.It seems difficult to integrate this nicely with the generic display and editing UI for qualifiers. TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: thiemowmde, Ladsgroup, Liuxinyu970226, Pigsonthewing, Bugreporter, Jan_Dittrich, Josve05a, Sadads, Pokefan95, gerritbot, DannyH, Micru, intracer, mkroetzsch, Aklapper, daniel, Steinsplitter, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, El_Grafo, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T115640: Link to a subclass list from each entity
Jonas added a comment. @Ladsgroup you could lower gas:maxIterations or add additional constraintsTASK DETAILhttps://phabricator.wikimedia.org/T115640EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: Smalyshev, Jonas, Lydia_Pintscher, Ladsgroup, StudiesWorld, Quiddity, Aklapper, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142087: [Task] prepare bot for quantity change fixes
Ladsgroup added a comment. I guess I wasn't clear, that's definitely not a new data type :D I meant a new type of boundary. It seems doable. Just we need an API to do that.TASK DETAILhttps://phabricator.wikimedia.org/T142087EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, LadsgroupCc: Ladsgroup, Edgars2007, Pasleim, Aklapper, thiemowmde, daniel, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T142087: [Task] prepare bot for quantity change fixes
daniel added a comment. @Ladsgroup close. Unbounded quantities are not a separate data type. They are just quantities with the upperBound and lowerBound not set. The bot should have two modes: convert +/-0 to unbounded, and convert the old default to unbounded (the old default was +/-1 for integers, but more generally, +/- the order of magnitude of the least significant digit). It should do this for all statements about a given property, and we'd need community consensus for each property (or for a list of properties). The relevant statements can be found via SPARQL. For now, I think it's sufficient to only do this for main snaks, not qualifiers, I think.TASK DETAILhttps://phabricator.wikimedia.org/T142087EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, danielCc: Ladsgroup, Edgars2007, Pasleim, Aklapper, thiemowmde, daniel, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T118000: Cannot use Chinese IME in label table
deryckchan added a comment. In T118000#2566359, @Liuxinyu970226 wrote: In T118000#2504503, @deryckchan wrote: In T118000#2504332, @Liuxinyu970226 wrote: Works for me under Windows 7 (tried both Sogou and MS IME), maybe a bug in Windows 8 or 10? Yes it was Win8.1 I had problems with. I haven't tried Win10 yet. So this is an #upstream bug? i.e. probably should report to https://answers.microsoft.com/ or https://social.technet.microsoft.com/ ? No that isn't what I mean. I meant this bug affects some platforms but not others. Input boxes on other sites - including other Wikimedia projects -behave normally.TASK DETAILhttps://phabricator.wikimedia.org/T118000EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: deryckchanCc: Liuxinyu970226, thiemowmde, Lydia_Pintscher, Aklapper, deryckchan, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T139862: Expand EasyQuery to work with more properties/ data types
Sjoerddebruin added a comment. In T139862#2563870, @Ladsgroup wrote: I see, it's fixed now Fixing edit (clear the cache) Sorry, but after clearing my cache I still have the same issue.TASK DETAILhttps://phabricator.wikimedia.org/T139862EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, SjoerddebruinCc: Sjoerddebruin, Aklapper, Zppix, Ladsgroup, Daniel_Mietchen, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T142694: [Story] Refactor Add-/Remove-Toolbar
Jonas edited the task description. (Show Details) EDIT DETAILSThis will refactor code from the toolbar controllers to the views and factory. The goal is to unify and reuse code for all views and store view specific logic within the views. The goal is to unify and reuse code for all views and store view specific logic within the views. [x] Clean up EditableTemplatedWidget and implementations https://gerrit.wikimedia.org/r/#/c/298754/ [ ] Introduce StructureEditorFactory https://gerrit.wikimedia.org/r/#/c/298755/...TASK DETAILhttps://phabricator.wikimedia.org/T142694EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: thiemowmde, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
gerritbot added a comment. Change 305620 had a related patch set uploaded (by Thiemo Mättig (WMDE)): Kill bogus "benchmarking" test https://gerrit.wikimedia.org/r/305620TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, gerritbotCc: gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
gerritbot added a comment. Change 305499 had a related patch set uploaded (by Thiemo Mättig (WMDE)): Replace time waster in SandboxTest with simple counter https://gerrit.wikimedia.org/r/305499TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, gerritbotCc: gerritbot, TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
thiemowmde added a project: Patch-For-Review.thiemowmde moved this task from incoming to in current sprint on the Wikidata board. TASK DETAILhttps://phabricator.wikimedia.org/T143389WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Triaged] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
thiemowmde triaged this task as "Unbreak Now!" priority.Herald added subscribers: Luke081515, TerraCodes. TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
thiemowmde created this task.thiemowmde added projects: Wikidata, MediaWiki-extensions-Scribunto, Continuous-Integration-Infrastructure.Herald added a subscriber: Aklapper. TASK DESCRIPTIONThere is a flaky test in the Scribunto extension that started to repeatedly fail for the same reason, wrecking my nerves and doing nothing good but (literally) wasting time: Just one of many recent examples: https://integration.wikimedia.org/ci/job/mwext-testextension-php55-composer/4322/console 16:09:00 1) LuaSandbox: Scribunto_LuaSandboxTests::testArgumentParsingTime 16:09:00 Unused arguments not counted in preprocess 16:09:00 Failed asserting that 0.5584210540008 is less than 0.25. 16:09:00 16:09:00 /mnt/jenkins-workspace/workspace/mwext-testextension-php55-composer/src/extensions/Scribunto/tests/engines/LuaSandbox/SandboxTest.php:75 The trivial reason why this fails is that this runs on a virtualized CI machine. There are other things running the same time, delaying execution. One simply can not rely on any minimum or maximum execution time of a specific snippet of code. This is guaranteed to fail. Suggested solutions: https://gerrit.wikimedia.org/r/305499 removes any code that measures CPU cycles with trivial counts. In consequence the test does not test any more what it was intended to test. The counts the patch introduces are correct: The hook is expected to be called three times. But the first two times should not add on top of the execution timer and the result getCPUUsage returns (search for luasandbox_timer_pause and luasandbox_timer_unpause in the luasandbox extension). @Anomie decided to block this patch with no way forward. A proper solution would be to mock the code that collects the benchmark results this test is currently testing. But the code doing this is not even part of this extension! Search for getCPUUsage. This is in luasandbox, which is a PHP extension written in C. I believe it's not even possible to mock this. https://gerrit.wikimedia.org/r/305620 just kills the thing. Remove Scribunto from the Wikibase CI. Seriously. If the extension is broken and we can not rely on their tests any more, having them in our CI is of no value any more. The contrary: all it does at the moment is causing harm. We can re-add it later when the issue is solved. TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T143389: [Bug] Scribunto_LuaSandboxTests repeatedly fails because it relies on code execution time
thiemowmde added a project: Wikidata-Sprint-2016-08-16. TASK DETAILhttps://phabricator.wikimedia.org/T143389EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: TerraCodes, Luke081515, Addshore, aude, hoo, Lydia_Pintscher, thiemowmde, Anomie, Aklapper, D3r1ck01, Izno, Wikidata-bugs, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Jay8g, hashar, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
