WMDE-leszek added a comment.
In T277362#6920735 <https://phabricator.wikimedia.org/T277362#6920735>, @daniel wrote: > In T277362#6919927 <https://phabricator.wikimedia.org/T277362#6919927>, @Legoktm wrote: > >> It just pushes the problem onto someone else, by stopping their development and forcing them drop everything just to unbreak their repo > > I was not aware this broke any tests in any repo - did it? > > My understanding was that there are no automated tests for the cross-wiki case in Wikibase. Because there are no such tests, the issue did not show up in CI. (Not blaming anyone but myself - I originally wrote the cross-wiki reloading code in Wikibase, and then I rewrote it for RevisionStore). 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. >> - in this case it hit everyone by stopping the entire train. > > I don't see why deprecation warnings should stop the train at all. I agree that they should be worked on with high priority, but why should they be treated as production errors? 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". >> That Wikimedia-deployed code was still using this hard deprecated code was identified on Saturday, once that identification was done, why did it have to rise all the way to a train blocker on Tuesday to get a revert? > > I learned about the issue from Hoo on IRC at 17:30 on Monday. I immediately started work on a fix. On Tuesday, that fix got a couple of rounds of review, getting the tests right wasn't trivial. However, the urgency wasn't clear at all, I didn't hear from the Wikidata team all day. 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. TASK DETAIL https://phabricator.wikimedia.org/T277362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, WMDE-leszek Cc: 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
