May 17 2021
May 14 2021
May 12 2021
May 11 2021
Moving this back into TODO to give someone else the chance to pick this up (as I wont work much more this week).
May 10 2021
I superficially looked at all tests in question, and I think they all serve a value. The only test that is a little redundant is Lexeme:Lemma can be edited (which is mostly redundant with can be edited multiple times).
This led to the discovery of T282440: ImageLinksDataUpdater::updateParserOutput confuses SHA1 and timestamp when calling ParserOutput::addImage.
The functionality that caused the problems here is covered in ImageLinksDataUpdaterTest (and additionally partly in FullEntityParserOutputGeneratorTest). That currently doesn't test the RepoGroup interaction, thus I will add another test case for that. Once that is done, I consider this fixed.
May 6 2021
Probably caused by 83e184670c24470223f593babfa7b5d05bee5cda.
May 4 2021
The runs last week failed (and no one noticed in time, see T281267: various weekly and daily dumps run from systemd timers are broken for that). The JSON dumps should appear as usual this week.
May 3 2021
Just wanted to note that using a template for all the properties on the page surely wont work (these are just to many), but IMO this is probably still useful for highlighting specific properties and for wikis which have fewer entries then Wikidata.
I've merged https://github.com/wmde/wikibase-release-pipeline/pull/163 (as there were no objections). Putting this back to to do, due to T281472: Remove latest, latest-bundle, latest-base tags from dockerhub.
Apr 29 2021
Fixed with https://gerrit.wikimedia.org/r/c/683574
I just grepped git diff origin/wmf/1.36.0-wmf.30..origin/wmf/1.37.0-wmf.3 client/ lib/ data-access/ as well and that seems to contain no further relevant changes, so once the three mentioned at the top are addressed we should be good here.
Apr 26 2021
Apr 14 2021
Such a check can (only) be done trivially if the job queue that is being pushed into belongs to the same wiki.
No idea, but that might be the cause. No idea if this is even happening still.
Not sure how much this is worth digging into or even trying to remove?
Not much IMO… but then again, having this around in a broken state could cause trouble later on (eg. if something starts using that field).
How hard do you think it would be to remove? I guess this would only be removal of the id from the data stored in the recentchanges row?
Trivial, but we need to make sure that nothing reads from this again (the ticket is ~1y old by now).
Apr 13 2021
Apr 12 2021
Apr 7 2021
Icinga sends alerts, and those would come to me I guess, which is probably not the best outcome :-)
We could use the wikidata contact group for that.
Mar 31 2021
Confirmed fixed now (after running composer update). Updating vendor will be done as part of T274821: Update data-values/* in mediawiki-vendor.
Mar 30 2021
I just +2ed the last backports here, and except for the question posed above and the missing release notes, this is done.
Addressed in https://github.com/wmde/Number/pull/135.
Mar 20 2021
Mar 17 2021
Mar 16 2021
I just +2ed all remaining patches. I suggest we go over the ones that are harder to backport with @Samantha_Alipio_WMDE and decide which ones are worthwhile doing.
The fixed 20210301 JSON dumps (very same content, only the structure was fixed) can now be found on dumps.wikimedia.org (and the old broken ones are in /bad).
Mar 13 2021
The above look good to me. I also just went through git log --no-merges origin/REL1_35..origin/master and found the following that looked interesting:
(in no particular order)
Mar 12 2021
I wrote a small script to fix these dumps (wikibase-json-dump-double-entry-fix) and that is currently running over the invalid dump (on stat1007). Once it is done, and we re-compressed the dump in both gzip and bzip2, we will provide a fixed up 20210301 JSON dump.