Fine with me!
Sun, Jul 21
Switched to weekly in the latest PR and also fixed the missing ;.
If you give it a +1 I'll go ahead and get it running in the coming days.
I like the changes. The page is much easier to follow now due to its shorter length, and also we no longer need to try and keep the same docs up to date in 2 places!
Also why captions even matter for T223792 - shouldn't getEntity look up by ID (which in case of MediaInfo is straight page id) not by caption?
Indeed, port 80 is hardcoded.
Thu, Jul 18
If elastic already has captions indexed then yes this could probably just use elastic. (There would be slightly more delay and potential unpredictability using elastic than some mysql tables like wb_terms).
Note to researcher.
The normal way of this happening would be via the dispatch system.
I imagine whoever does this research will need to look into that a fair bit! :)
I don't think wb_terms should be used at all for media info.
A custom system or new table or set of tables should be decided on, created, and populated.
Temporarily using wb_terms just to remove it would cause more trouble that it is worth and could just lead to it still existing in a few years and us having to do another massive migration.
Not sure what we would gain by adding a panel per entity type.
Not sure if this is done or not, the estimation should perhaps take that into account.
See T227032 :)
Wed, Jul 17
Can you confirm that it is still happening on the latest version of the latest tag of the image?
Could you post the image hash and digest you are using?
And also anything you are modifying the image with at runtime (file mounts, env vars, etc)
The re design for items and properties gas already happened.
Mediainfo could benefit from a different design if there are only captions.
The patch above does tracking of # of slots by type for wikibase repos (so commons and wikidata).
I don't think there should be any security implications with this script.
Currently it is set to run daily, there is also a weekly cron it could be moved to.
Tue, Jul 16
Wed, Jul 10
Yes, but this ticket is talking about daily browser tests, not on patch browser tests.
Re opening as we will want to add this to the Local settings file that comes as part of the image :)
Is 1.34 actually required for anything?
Probably best to check with the origional Devs :)
Otherwise let's change that down!
Tue, Jul 9
Looks very weird as in?
I don't know how much work this is.
@Lydia_Pintscher should this still be on the campsite?
Is this ready to be done?
Can we get this added to wikibase.git? :)
The endpoint is hardcoded in https://github.com/wikimedia/analytics-wmde-toolkit-analyzer/blob/35ae8f3796f88443ab9bec18c82881b7a0500162/analyzer/src/main/java/org/wikidata/analyzer/Fetcher/WikiDataFetcher.java#L29
From the logs:
For the TODOS...
So most if not all of T119753#1838227 in theory still needs to be done.
But it is all probably pretty low prio, so I'm just going to wrap this ticket up as resolved now.
But if we find a way to wrap WANObjectCache into PSR6 compliant interface won't that be even better.
Same from here
Mon, Jul 8
Indeed, let's get rid of oldid :)
So we (WMDE) actually made a daily namespace in graphite for tracking data daily instead of minutely.
We have been using daily metrics there generated from various scripts for a few years now.
That could be an option.
Or we could alter the docker file to just grab the extension at a specific pinned commit for 1.33 that we know works.
Sat, Jul 6
Thu, Jul 4
Would representing captions as captions rather than labels in the JSON structure help?
Or rather than pretending media info entities are totally like items / properties just have totally different handling for them when it comes to indexing?