[09:03:03] benestar|cloud: around? [10:18:54] Per the build tests failing it looks like something broke PropertySuggester (again).... I'll have a look at this today aude etc. :) [10:20:46] oh noes [10:24:32] Thiemo_WMDE: I am going to poke DV Common in a few mins [10:24:40] 0.3 -> 1.0 [10:24:49] This is the first breaking rel since 2013 apparently [10:25:41] please keep 0.3 [10:26:02] i picked this version number for a good reason. [10:26:35] with the stringparser merged i think the 0.3 release can be done without any more changes. [10:26:43] do you plan to change anything? [10:27:24] just the version number [10:27:30] What's the reason for keeping 0.3? [10:28:33] see https://github.com/DataValues/Interfaces/pull/14 [10:29:15] all the datavalue components are far from becoming "official". [10:30:00] they *ARE* still in a pre state. switching to a "final" version number gives the wrong impression. [10:30:41] Thiemo_WMDE: "1.0" is not "final". You can happily do breaking changes as you like and have a 2.0 or whatever [10:31:05] Would we not be at DM 0.15 now if we applied the same logic there? [10:31:17] yea, as we do in datamodel now, talking about a 5.0 in just a few weeks. [10:31:53] yes, datamodel should be at 0.11.0 or something in my opinion. [10:32:00] Thiemo_WMDE: we already talked about this at some point [10:32:05] And semver.org settled it [10:32:08] I wonder what changed [10:32:10] Look at http://semver.org/ [10:32:16] search "How do I know when to release 1.0.0" [10:32:51] All 3 points are these case for this code [10:33:20] DM should most definitly not be 0.something according to semver [10:33:51] switching from 0.2 to 0.3 is not wrong. it does not block us from doing a 1.0 later. [10:33:59] lets please keep this simple. [10:34:22] How is releasing as 1.0 less simple? [10:34:35] i just explained that. [10:35:44] really? which part of what you wrote was about simplicity? I don't see any. And I don't know why using 0.3 would be more simple [10:36:07] Doing an additional release to fix our misuse of semver is not more simple [10:36:27] What do you propose, us releasing this as 0.3 and then releasing the same thing again as 1.0? [10:36:52] +264, -0 (wikis getting arbitrary access today) [10:36:58] https://gerrit.wikimedia.org/r/#/c/230990/1 :) [10:37:28] huzzah [10:39:59] jzerebecki: It would be great to run PropertySuggester & WikibaseQuality* tests as a postmerge job on jenkins for the Wikibase repo.... Thoughts? [10:46:43] JeroenDeDauw: "the same thing again"? what do you want to prove or disprove here? [10:49:18] the datavalue components are all still in flux and will change in the near future. we will rework them and have other, easier to understand splits between the components. we are talking about this since months. 0.3 is not wrong. it's more honest. it reflects the fact that the component will drastically change before an "official" 1.0 release. [10:52:55] Thiemo_WMDE: so you disagree with semver.org? [10:53:13] Because as I read it, it says 0.3 is in fact wrong [10:53:27] what type of argument is that??? [10:54:20] Because it's the versioning standard that we are using? [10:55:25] Jonas_WMDE: I still don't get it... [10:56:52] one can use a banana for scale, but the banana I gave you is very small so everything you will scale with it will be very big [10:58:40] using semver.org as an argument does not lead anywhere. i read it and i see that it in fact proves me right. these components should still be in the 0.x range. [11:00:42] addshore: are you fixing property suggester now? [11:01:13] otherwise i can take care of it now [11:01:25] Thiemo_WMDE: how does semver say they should still be in 0.x? [11:02:09] i can turn this around. how does semver say they should be in 1.x? [11:02:31] "If your software is being used in production, it should probably already be 1.0.0. " [11:02:37] "If you have a stable API on which users have come to depend, you should be 1.0.0. " [11:02:43] "If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0." [11:02:44] "probably". no "must" or anything. [11:02:51] "stable". which it is not. [11:03:11] "worrying". which we are not. [11:03:17] It's not been broken since 2013, and we have several packages depending on it [11:04:02] they will all work fine with a 0.3. why are we wasting time on discussing this? what do we win by changing the version number scheme NOW? [11:04:13] I'm not going to play with the words. If you really think it's intended like that then I guess I can't convince you otherwise [11:05:00] aude: yup [11:05:01] We get out of the 0.x range which is intended for initial dev and thus can properly distinguish between bugfix and feature releases [11:05:13] aude: just put a patch up, making sure jenkins likes it then will stick on the v1 branch too [11:05:36] why do you think that the 0.x version scheme became so horribly wrong within the past few weeks that you think you must convince everybody else? [11:06:06] No I don't [11:06:14] oh balls... forgot PropertySuggester was on github.... just pushed it straight to master :D [11:06:23] We've been correcting our misuse of semver for some time already [11:06:27] addshore: ok :) [11:06:30] Generally at the next breaking release of a component [11:06:36] aude: https://travis-ci.org/Wikidata-lib/PropertySuggester/builds/75247573 ;) [11:06:46] addshore: this is property suggester... there is no v1 [11:06:53] but we need to tag it [11:07:07] ahh, okay! ;) [11:07:39] and looks like you pushed to master (ok) [11:07:49] looks sane :) [11:07:51] yeh, whooops.. [11:07:56] at least the change is okay ;) [11:08:02] i wanted to avoid exactly this discussion by doing the most simple thing and not changing anything. [11:08:03] :) [11:08:12] hurray. [11:08:12] we should perhaps get pushing to master directly turned off on all our github repos aude ;) [11:08:14] do you want to tag it? [11:08:26] addshore: if that is possible [11:08:37] aude: yup, you just have to email github and they will do it! [11:08:44] wow [11:08:50] Tobi_WMDE_SW: ^^ ;) might be worth you looking at that [11:08:55] tag + update release notes [11:09:12] aude: 2.4.0? ;) [11:09:19] the versioning of this one is totally messed up... [11:09:28] addshore: suppose so [11:13:43] aude: https://github.com/Wikidata-lib/PropertySuggester/pull/137 [11:18:59] addshore: https://github.com/Wikidata-lib/PropertySuggester/pull/138 (just something i noticed) [11:19:15] going for lunch nowish [11:20:24] kk =] [11:47:48] This is kind of lame but... [11:48:11] Can anyone tell me where I can look up the current location of an ICE train in berlin? :) [11:48:46] ICE1645 should have been here 30 mins ago but I haven't been able to find it anywhere... [11:48:57] (Sorry for the ot spam) [11:49:39] hm. I saw a website a while ago that had "live" train positions, but the data for germany was apparently based on timetables so I'm not sure it would be accurate [11:50:07] Ah damn [11:50:21] There is a board listing arrivals but it doesn't have the train I'm looking for [11:52:02] Yuvi|Vacation: what station are you at? [11:52:21] addshore: berlin central [11:52:52] Waiting for someone coming in from koln [11:53:03] you in berlin tommorrow? [11:53:45] addshore: nope, ccc camp :) [11:53:52] addshore: I'm in berlin again on 29th [11:53:54] Or 28th [11:54:04] I will most definitely come by the office as well [11:54:34] cool! [11:54:38] Change in the route! , [11:54:38] approx. +60 , Reason: Additional stop for travelers boarding / alighting [11:54:52] addshore: oh, where did you find that? [11:54:58] 1645 or 1655? searching bahn.de for trains from köln to berlin shows a train that's an hour late [11:55:11] I found a form Yuvi|Vacation, not sure if I am using it right though [11:55:11] http://reiseauskunft.bahn.de/bin/bhftafel.exe/en?ld=15064&country=GBR&rt=1& [11:55:16] 1645 says the ticket [11:55:25] * Yuvi|Vacation stares at the .exe [11:55:38] That's a cgi running on some iis I guess.... [11:55:42] Yuvi|Vacation: yeh..... i know...... [11:56:47] I'll let you play with it ;) [11:57:19] addshore: aha! Platform 11 - that's what I was looking for [11:57:24] So I can go camp there :) [11:57:30] :D [11:57:36] Thank you very much, addshore and nikki [11:58:12] :) [12:24:32] https://www.wikidata.org/w/index.php?title=Q3938&type=revision&diff=240309106&oldid=239967577 :) [12:25:06] what, Yuvi|Vacation is in berlin? [12:25:21] come visit after camp :) [12:37:42] https://de.wikipedia.org/wiki/Benutzer:Aude :D [12:37:48] Lydia_WMDE: ^ [12:40:27] https://fr.wikipedia.org/wiki/Utilisateur:Aude [12:42:07] kitties \o/ [12:42:32] ouh :) [12:43:33] japanese cats: https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Aude [12:44:16] are there any non-wikipedia sites left which don't have arbitrary access? commons I guess? [12:44:42] nikki: commons [12:44:52] and then wikinews and wikibooks don't yet have data access at all [12:44:58] ah [12:45:11] when they do get data access, then they can have arbitrary access right away [12:45:22] https://phabricator.wikimedia.org/T100788 [12:45:45] matej_suchanek: still scheduled for tuesday [12:46:17] 12 remaining Wikipedias [12:46:21] yep [12:47:54] aude: what happens if you insert the user page code to the meta page? [12:48:02] those kitties I mean [12:52:37] matej_suchanek: meta doesn't yet have wikibase enabled :( so won't work [12:52:54] yes but what about client non-created user pages [12:53:05] on project where arbacc has been enabled [12:53:14] i can try [12:53:28] don't think it works though since the pages are transcluded [12:53:32] does meta need wikibase enabled for us to be able to add sitelinks to it? [12:54:05] nikki: yes [12:58:21] ah... is there a ticket in phabricator for that? I'm not seeing anything but maybe I'm not searching for the right things [12:58:51] git stat [13:01:27] nikki: not that i can find [13:01:38] * Nemo_bis has no idea why meta wasn't done yet [13:01:40] I found two similar [13:01:54] https://phabricator.wikimedia.org/T73685 and https://phabricator.wikimedia.org/T54971 [13:02:16] meta is multilingual, same problem as Commons, isn't it? [13:02:45] matej_suchanek: that is true :/ [13:05:01] matej_suchanek: why is multilingualism an issue? [13:05:10] AFAIK sitelinks don't need knowledge of language [13:06:05] Nemo_bis: for arbitrary access [13:06:09] but you are right about site links [13:06:16] +1 [13:20:41] I'm oddly surprised it's the first time someone isn't convinced by my mushers :p [13:21:07] multichill: I didn't really understand what you mean by "the background" ? [13:21:19] so I'm note sure I answered that [13:31:03] I an waiting for Meta to have sitelinks in Wikidata, would be great to finally have that there [13:43:43] Romaine, Nemo_bis: created https://phabricator.wikimedia.org/T108825 [13:44:15] thanks! [13:47:07] is there a way to get a list of English labels from all items with P220? [13:54:48] addshore: whats the deal with the removing of old copies in lib? [13:55:07] I'd like to poke stuff and want to avoid conflicts [13:55:54] removing of old copies? O_o [13:56:09] entity->copy? [13:56:17] addshore: no, the stuff we moved [13:56:26] they are mostly all gone already [13:56:34] what's left>? [13:56:49] just stuck on the last, urm, 3 things [13:56:59] all because of the stupid exception stuff..... [13:57:06] once stuff is gone we can have another look at lib and hunt for things to move [13:57:35] Just started looking at it. TermBuffer, PropertylabelResolver and changing the use of UnresolvedRedirectException / Storage exceptions, thats it [13:57:36] The two fields dropped from UnresolvedRedirectException? [13:58:16] I just threw this up to see what would happen.. https://gerrit.wikimedia.org/r/#/c/230994/ [13:58:46] got to poke that more I guess, then do the UnresolvedRedirectExceptipon stuff, then moving the final 2 classes should be trivial [13:58:58] derp at us not including this in 1.1, was rather easy https://github.com/wmde/WikibaseDataModelServices/pull/40 [13:59:31] addshore: mind if I replace the test you added to https://github.com/wmde/WikibaseDataModelServices/pull/22 with something else? [14:00:01] JeroenDeDauw: go for it! [14:02:27] Romaine: wouldn't something like autolist work? [14:03:00] well, I use this to get the values for 218, but now I am looking for the labels instead: https://wdq.wmflabs.org/api?q=claim[218]&props=218 [14:04:07] Romaine: I think Quarry could help you [14:04:53] does quarry have access to statements on items? [14:05:29] not for now [14:05:32] Romaine: https://tools.wmflabs.org/wikidata-nolabels/ work for me, with "claim[218]", no languages specified and labels "fr" specified [14:05:42] I mentioned autolist rather than just wdq because autolist loads the labels [14:06:36] I need to have the Q.. + label [14:06:43] Harmonia_Amanda: now it works here [14:07:20] thanks! [14:07:39] but I would have expected that such also can be done with https://wdq.wmflabs.org [14:07:57] what are you doing anyway? :) [14:10:50] addshore: https://github.com/wmde/WikibaseDataModelServices/pull/22 [14:21:09] arbitrary aude, hotfix hoo, leader Lydia_WMDE, we can do an alphabet in codernames ;-) [14:21:22] rofl [14:21:29] :D [14:21:38] I love that :p [14:21:38] hah [14:22:40] Harmonia_Amanda: Hi, just scroling back. With background I meant maybe some context or the story around it. Why you did it. Why it's cool :-) [14:23:05] I did it because I love sled dogs :p [14:23:32] and because I could [14:24:40] Excellent reasons! [14:25:25] and because there isn't a complete database anywhere [14:25:42] each race has it's own results on its own website [14:25:57] difficult to see the complete career of a musher [14:26:21] so wikidata is great for centralizing information [14:26:33] Yeah! [14:31:58] well, i'll be great when we could add the times of each musher in each race :p [14:32:34] addshore: did you see anything in lib that could still be moved? [14:33:52] JeroenDeDauw: I believe I moved all of the stuff that is only used in either repo or lib to those places [14:33:59] will have a quick scan through now for other stuff [14:34:28] addshore: as far as I can tell there is nothing left that can be moved to DMS without first non-trivial refactoring of the thing in question [14:34:56] addshore: that does leave things in Repository and Client though... it's not because they are just used there ATM that they are best located there [14:37:26] The reporting dir in Lib doesnt seem to bind to anything at all and could probably be shipped out to some lib [14:37:58] so could the SerializationModifier I added, but thats a minor thing we would like to kill anyway... [14:39:54] If TitleValue in core was actually in its own lib, ie. the start of a set of value objects for mediawiki stuff then we could probably ship a load of other interfaces etc out into other libs.. [14:40:07] eg EntityIdLookup [14:41:24] addshore: I don't think SerializationModifier on its own quite justifies its own library. Probably better to stuff it together with something else even if it's not 100% nice [14:41:36] Jonas_WMDE: ^ hey look, I'm arguing against adding a library ;p [14:42:07] addshore: agree on the reporting stuff... that's infrastructure code esentially [14:42:16] xD [14:42:30] addshore: though again I'm not sure about us creating a library for that [14:42:34] tbh, I was surprised there wasn't already a library doing something like that [14:42:48] There are libraries that do this. And sure we can't us them, but what about moving this into core? [14:43:06] Since some of it binds to core anyway and its only used by stuff that binds to core [14:43:35] And if you care about using the interface elswehere, then you can just define a new interface in that elsewhere and work with an adapter. Very simple interface anyway [14:47:42] addshore: "something like that" are you talking about MessageReporter? [14:48:28] addshore: actually there is one which started out from the same code [14:48:30] https://github.com/onoi/message-reporter [14:49:41] addshore: perhaps we should just create a ticket on fidning a new home for this code and discuss there? ;p [14:49:49] Assuming there is not one already? [14:50:48] are the WMF api servers a bit sick? Seem to be getting quite a few non-json responses with my bot [14:52:35] addshore: hm.. what exactly do you want me to look at.. I'm a bit lost [14:54:30] JeroenDeDauw: a ticket sounds good [14:54:46] Tobi_WMDE_SW: the possibility of turning off pushing to master on all of our github repos (github will do it if you email them) [14:58:50] *tries to decide if EntityLookup should only return nulls or throw something* [15:01:32] addshore: https://phabricator.wikimedia.org/T108835 [15:02:16] addshore: Tobi_WMDE_SW: is there a problem with people pushing to master? I can't remember anyone abusing that [15:02:36] addshore: hm. need to think about that [15:02:50] addshore: Tobi_WMDE_SW: at the same time it is used for valid stuff: for instance editing the readme or similar and not having that go through cr [15:02:58] JeroenDeDauw: I just accidentally did it, again ;) [15:03:12] addshore: bad addshore ! ;p [15:03:15] JeroenDeDauw: Tobi_WMDE_SW people can still open PRs and then self merge [15:03:19] addshore: but shouldn't that only be possible with -f? [15:03:55] err. If you push to master with -f in a case where that is actually needed you are doing something really evil :) [15:04:10] Tobi_WMDE_SW: no, you do not need -f. As long as you don't conflict with master [15:04:30] hm.. ok [15:04:54] addshore: needing a PR for every edit to some doc file is kinda annoying [15:05:24] addshore: is there no setting that allows you to block yourself from doing that?;p [15:05:43] addshore: anyway, where is this thing you accidentally pushed? I'll haz a review [15:06:32] probably not ;) [15:08:19] https://github.com/Wikidata-lib/PropertySuggester/commit/10c283e431e6a8d032b261064cd75567d2fb86a9 nothing major, fixing what I broke by removing lib stuff [15:09:04] addshore: +2 :) [15:10:19] addshore: heh, I did not realize that most stuff in the reporting directory is actually this ExceptionHandler stuff [15:11:37] JeroenDeDauw: indeed [15:11:52] can't we just use that library you linked (I havn't actually looked at it yet) [15:12:20] addshore: so we just have MessageReporter and ObservableMessageReporter in lib [15:12:26] These don't depend on anything [15:13:14] Yeah, that lib has that stuff as well. However, it's a third party lib, so WMF says no [15:14:51] addshore: that stuff is actually literally just 8 ELOC. Which suggests to just copy it rather than introducing a new dependency [15:15:15] ExceptionHandler has more code though, with some binding on MW [15:15:57] oh yeh, *sees a call to wfLogWarning etc now* [15:16:53] You could just add an extra interface there tho [15:17:18] Looks like this stuff is only used in maintenance scripts or things created for maintenance scripts [15:17:28] So it can be moved to core and serve our current usecases [15:17:50] That'd not be nice for if we'd switch over some maintenance scipt to use Symfony Console or whatever [15:25:50] JeroenDeDauw: https://gerrit.wikimedia.org/r/#/c/230994/ , what are your thoughts on the 2 last paragraphs in the commit msg? Specify an exception that the lookup interface can throw and make these extends that exception? I guess either than or these exceptions must die... [15:27:41] addshore: we changed the contract? [15:27:54] * JeroenDeDauw goes to double check [15:29:38] It used to throw storageexceptions, which had to change [15:30:56] but now trying to use it it looks like some stuff may have to throw something [15:31:30] Right. We did change it (or rather, I did) [15:32:25] addshore: one min, ordering foodz [15:35:17] addshore: for RedirectResolvingEntityLookup and EntityRedirectResolvingDecorator... should that exception then not just be caught and null be returned instead? Or does that create some problem? [15:37:03] addshore: well, if we need to provide behaviour more than either getting an entity or null, then we indeed not to add an exception that the interface can throw [15:39:37] addshore: huh, apparently it was you that removed the tags, not me [15:40:11] addshore: anyway, let's add a new exception then? [15:44:27] JeroenDeDauw: yeh *agrees* [15:44:40] for the next release and then I cam move these final few things with that one [15:44:43] with the other stuff [15:49:54] addshore: do you know what happens with this EntityAccessLimitException? [15:50:01] Is it actually caught somewhere? [15:50:10] No hoo on irc :( [15:53:30] JeroenDeDauw: not looked yet [15:53:57] JeroenDeDauw: doesnt look like it is caught anywhere [15:54:55] addshore: if there would have been code that just catches that exception, things would be more difficult [15:55:12] Though it indeed looks like the code could just have thrown \Exception, and worked in the same way [15:55:34] Stuff does catch the UnresolvedRedirectException [15:57:57] Looks like those can be replaced by a CouldNotLoadEntity or whatever exception [15:58:17] You still want to know the redirect stuff failed [15:58:27] Though that can be done through the exception message rather than the type [15:58:34] Looks like the message is just getting ignored now [15:59:06] That will likely also fix issues in the code doing the catching ATM [15:59:28] SInce it's just handling UnresolvedRedirectException and not behaving properely if another exception is thrown [16:01:49] Right, laptop just crashed, back in a bit ;) [16:02:12] addshore: guess it could not handle the exception? [16:02:50] Lydia_WMDE: Seeing quite frequent 503's on the API [16:03:14] multichill: that's doesn't sound good :/ [16:16:07] multichill: what addshore says [16:17:23] is it a particular call that's an issue? [16:17:26] or general? [16:17:51] PhpStorm 9.0.1 \o/ [16:20:07] Dunno, just see it popping up every once in a while [16:20:28] Bot just waits a moment and continues where it left off [16:21:23] food [16:21:30] nomnomnom [16:32:02] fml, all the phpstorm files died [16:33:47] ?! addshore killed all the phpstorm files?! outrage! burn the addshore! burn the addshore! [16:34:12] *waits for phpstorm to rebuild indexes etc for core and all extensions.....* [18:14:01] Lydia_WMDE: addshore: pywikibot.data.api.APIError: readonly: The wiki is currently in read-only mode ? [18:14:03] Wut? [18:14:08] whut [18:14:20] multichill: using what api module? [18:14:26] yup [18:14:44] Just came back from food and noticed to crashed bots :-( [18:15:14] 19:16 last edit so 59 minutes ago [18:15:54] if you restart them is it still happening? [18:16:38] No, just a glitch [18:16:52] thats an odd error though, readonly.... [18:18:21] u'servedby': u'mw1189', u'error': {u'info': u'The wiki is currently in read-only mode', u'readonlyreason': u'The database has been automatically locked while the slave database servers catch up to the master', u'code': u'readonly', u'help': u'See https://www.wikidata.org/w/api.php for API usage' [18:19:02] And u'mw1199' [18:20:10] addshore: Bit hard to reach the 100.000 paintings this way ;-) I'm now at 99608 and I was hoping to reach it tonight [18:21:10] ahhh, lots of db lag then [18:21:29] I would have thought that would be a different error code, but I guess readonly is okay! [18:22:36] multichill: do you happen to have any scripts for matching unlinked disambiguation pages to existing items? (or if not you, do you know of anyone else who does?) [18:26:57] as far as I can tell, shwiki has about 3000 of them with (razvrstavanje) in the title, and it seems like something that someone would have already made some bot for... [18:29:04] No, I haven't [18:29:29] Last time I looked for disambiguation pages on nlwp not tagged and linked I ended up with just 5 pages so I figured someone else was already doing that [18:29:45] ah [18:30:23] https://www.wikidata.org/wiki/Special:Contributions/BotMultichill <- I am matching paintings with their painter, next up, 2000 J. M. W. Turner paintings, sigh [18:33:12] Lydia_WMDE: hi! [18:33:21] remember our conversation at Wikimania? [18:33:39] did you write a summary of it anywhere by any chance? [18:35:52] remember our conversation at Wikimania? because I don't! <- ;-) [18:38:07] better the question: do you remember our conversation before an after drinking? [18:38:39] I didn't drink much at Wikimania this time. Was ill most of the time. [18:47:55] aharoni: uhhhhh which one do you mean? :D [18:48:00] also hi! [18:49:35] Lydia_WMDE: about auto-created stubs (I forgot your official name for it) and about extended link syntax for non-existent articles [18:49:49] aharoni: ah article placeholder [18:49:55] yes [18:49:55] lucie started working on it [19:02:58] aharoni: that is what they all say [19:03:12] "I didn't drink much" [20:46:24] PROBLEM - wikidata.org dispatch lag is higher than 300s on wikidata is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1427 bytes in 0.120 second response time [20:47:17] :O [20:56:07] do there exist dumps which cover classes and subclasses so I can generate a hierarchy of classes used on wikidata? [21:02:40] sjoerddebruin: that certainly does not sound good indeed... [21:02:57] !panic | icinga-wm [21:02:57] icinga-wm: https://dl.dropboxusercontent.com/u/7313450/entropy/gif/omgwtf.gif [21:38:08] aude: around? [21:43:26] hoo: could you take a look at https://gerrit.wikimedia.org/r/#/c/230247/ ? [21:47:11] +1ed [21:47:28] hoo: great, thanks! [21:47:40] I imagine ops should +2 it then [21:54:59] hoo: ? [21:55:11] quickly looking at the dispatcher [21:55:50] aude: On that already [21:55:54] don't worry [21:56:07] Just wanted to avoid two people looking at that ;) [21:56:32] ok :) [21:56:41] * aude is at a hostel and has to go to sleep soon :) [22:03:28] Ok, good night :) [22:09:17] * hoo waits for icinga to tell us that stuff is good again [22:09:54] RECOVERY - wikidata.org dispatch lag is higher than 300s on wikidata is OK: HTTP OK: HTTP/1.1 200 OK - 1423 bytes in 0.183 second response time [22:16:44] Running 3 additional dispatchers (on terbium), yet lag is growing [22:21:05] 5 now (2 more on tin) [22:22:04] ~ 200 edits/ minute, so nothing unusual there [22:33:47] addshore: https://phabricator.wikimedia.org/T96264 would run the tests from all extensions in our build for each build and core change [22:34:40] addshore: next step would be having a composer based version of that job containting the same extensions [22:37:34] PROBLEM - wikidata.org dispatch lag is higher than 300s on wikidata is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1427 bytes in 0.149 second response time [23:25:23] RECOVERY - wikidata.org dispatch lag is higher than 300s on wikidata is OK: HTTP OK: HTTP/1.1 200 OK - 1415 bytes in 0.184 second response time