daniel added a subscriber: thcipriani. daniel added a comment.
In T277362#6920796 <https://phabricator.wikimedia.org/T277362#6920796>, @WMDE-leszek wrote: > It is indeed very unfortunate that there has not been automated tests for this functionality. It would have given the issue more visibility and faster. > WMDE has created tests for this recently -- this is how we identified the problem on Monday -- but he have not yet integrated it into Wikimedia Jenkins CI. I expect us to do this in a couple of weeks. Oh, that's excellent! I'm curious about what approach you took for these tests. Having them in CI would have prevented to offending code from being merged. > If blocking the train on this issue -- which, BTW, got ultimately triggered by T277593 <https://phabricator.wikimedia.org/T277593> - WMDE has been the whole day going back and forth in internal chats whether this is a train blocker or whether all will be fine when the code lands in production -- was too extreme, it maybe would be good to have some clarity on how those deprecation warnings, and the exceptions/errors logged stemming from them should be treated. In my eyes treating them as a train blocker has been in line with the recently announced "new line on logspam". I generally agree with the stricter line on logspam. But I do think that halting the train for deprecation warnings does more harm than good. Perhaps @brennen and @thcipriani can chime in on that. Generally, halting/reverting deployments should be done to prevent damage to the site. Halting/reverting on logspam seems like a desperate measure, intended to make sure that warnings in production are actually prioritized. In this case, the warning was harmless (deprecation warnings indicate that things are still working properly), and the issue was already being worked on. Halting the train just caused more work for more people. > Point taken, we should have been more active in communication about this problem outside of WMDE (virtual) office. Something we shall improve in the future. I notice that neither this task nor T277593 <https://phabricator.wikimedia.org/T277593> is on any PET board, and I wasn't pinged on the task, even though it became quickly clear that the cause was in core. Pinging the relevant teams on components (in this case, #mediawiki-revision-backend <https://phabricator.wikimedia.org/tag/mediawiki-revision-backend/> and #platform_engineering <https://phabricator.wikimedia.org/tag/platform_engineering/>) would have helped getting more attention on this more quickly, and to coordinate on the way forward. TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, daniel Cc: thcipriani, dancy, Legoktm, RhinosF1, brennen, Lucas_Werkmeister_WMDE, Ladsgroup, Addshore, hoo, daniel, WMDE-leszek, toan, Aklapper, maantietaja, Hazizibinmahdi, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
