Software developer on the Wikidata team at Wikimedia Germany (he/him, Berlin timezone). Private account: @LucasWerkmeister.
User Details
- User Since
- Apr 3 2017, 2:45 PM (311 w, 5 d)
- Availability
- Available
- IRC Nick
- Lucas_WMDE
- LDAP User
- Lucas Werkmeister (WMDE)
- MediaWiki User
- Lucas Werkmeister (WMDE) [ Global Accounts ]
Fri, Mar 24
If there are open Addbot patches
Apparently the GitHub action deploying the new version had a strange error (both in the “staging” and “production” runs):
Very cool, thank you!
Thu, Mar 23
Oh, I didn’t realize that the branch-deploy npm script runs as part of CI test builds. You should be able to see the language selector here, then: https://901247--clicky-sparqly.netlify.app/
We intentionally haven’t deployed it to https://query.wikidata.org/querybuilder/ yet. I guess the easiest way to verify it would be via Netlify, similar to T324653, but I don’t know how to publish it there.
Wed, Mar 22
Tue, Mar 21
Mon, Mar 20
The basic query builder is merged; still missing are keyboard navigation, possibly further mobile / RTL changes, and also probably saving the selected language in local storage (or a cookie or whatever).
This turned out to happen naturally as part of T328148: LangSelector added to Query Builder; Add autonym in Language Selector Button includes a test for it.
Hm, if this is still happening according to T332540 after the above change was merged, then that might not have been enough to fix the issue :(
We currently use Husky v1, which installs itself by generating a script for every possible Git hook in .git/hooks/, silently overwriting any already existing hook there. The latest version is v8, which works differently: it changes the core.hooksPath Git config to point to .husky (see this blog post for details), which turns the hook in .git/hooks/commit-msg into dead code.
Mossi is fixed (good), but Tswana is still open AFAICT.
Regex Format constraints currently show only the regex.
Thu, Mar 16
Depending on how we implement a no-verbose-printing-by-default setup, you could set something like putenv( 'MW_PHPUNIT_VERBOSE="1"' ) somewhere in Wikibase's setup code when debugging a task, to swtich back on the dot printing. Would that be acceptable?
I tried updating the ->update() call in SqlIdGenerator, but ran into problems (T332329). I think we can consider this task done in the meantime; git grep -Fe '->select' doesn’t find any remaining unconverted uses.
It turns out that SelectQueryBuilder also doesn’t support ->where( $dbr::ALL_ROWS ), though it’s not as much of a problem there because you can just omit the ->where() call.
Apparently these test failures are due to the test changes? When I [revert them](I3a2b3655cecd12fa91d2c58c04479e1e4fd2bb91), check php passes again. o_O
Wed, Mar 15
I’m pretty confused by the Gerrit discussion on that old change, but if I understand correctly, I guess we can just remove the transaction around the big loop in run()? Having beginAtomic() / endAtomic() around the entire contents of run() doesn’t seem very useful indeed.
FWIW, I tried running our browser test suite against Wikidata.
Okay, looks like it’s not a general problem after all. Must be something wrong with my change, though I have no idea what…
No error in the php81 gate-and-submit for this tiny change so far either…
Okay, both the test and php pipelines succeeded there now. Untagging shared build failure while it’s unclear that it really affects more than just the one change. Let’s wait for a proper gate-and-submit on another Wikibase change and see how that goes.
Hmm, it doesn’t seem to happen in the check php build for the above change so far. Perhaps there’s some unexpected issue with the Gerrit change where the gate-and-submit errors happened?
(Looks like https://gerrit.wikimedia.org/r/c/labs/codesearch/+/898060 is the relevant Gerrit change.)
I guess so? Looks fine here as well now.
Tue, Mar 14
It should behave the same way that shift-click or control-click normally behaves on buttons, opening the new lexeme in a new tab or new background tab.
So the first of the above changes, Make DateFormatParser accept more Asian/Chinese date formats, enables Wikibase to parse dates like “2023年3月12日” in Japanese as 2023-03-12. That change seems unproblematic and is good to go, I think.
Mon, Mar 13
(FWIW, the same YubiKey now does require touch as expected – ever since I got a new work laptop, IIRC. Slightly weird but not the end of the world.)
Should the current user interface language be part of the shareable link or not?
I believe this is done now, all production environments use docker-registry.discovery.wmnet/wikimedia/wikibase-termbox:2023-03-06-101138-production which is based on Node 16.
Thu, Mar 9
I agree that scrolling through the progress indicators is annoying when looking for test results, but I also find it quite helpful while the tests are still running.
selenium-daily-beta-WikibaseLexeme (various error messages)
Can I take one step back and ask what are you using this max lag measure for, and how?
Tue, Mar 7
Just leaving a pointer here that for Wikidata production we solved essentially the same issue in T301461. (TL;DR: we also went for Cache-Control: no-cache. Keep in mind that applies not only to index.html but also to embed.html!)
Tagging this as an incident follow-up – while the maxlag was high, edits slowed down drastically (which is the correct response to high maxlag ^^) – see Grafana:
Mon, Mar 6
double check if any commits were missed while it was broken and if so, push them to the respective places
Did we do this?
It’s finally working again.
Apparently there’s a v1.21.3 now (Dependabot change), we can check if that still has the regression or not.
It looks like the Jest 28 upgrade only changed the meaning of the diagnostics: false flag in jest.config.js to also hide all the TS errors. If that flag is removed (which we ultimately want), then the errors are still there 😩
Pulling into the sprint to reflect that we worked on it; post-hoc estimated as “no smaller than 5 and no bigger than 8”.
Fri, Mar 3
Proposed fix: https://github.com/wmde/Time/pull/167
FWIW, @toan is indeed no longer working at WMDE. I’ll see if I can find someone on our side who knows more about the offboarding process.
Thu, Mar 2
CC @Krinkle and @Ladsgroup from build: Change diffConfig to use git-stash instead of git-add yesterday.
Wed, Mar 1
While we should of course handle this without crashing, it’s also clearly not a valid request: the code that is making these API requests is also broken. From GitHub search, wd-recon-lang seems to come from OpenRefine, especially the preview-renderer:
Can be reproduced locally with something like { "lang": "core-recon/wd-recon-lang" } in the options parameter, e.g.: