daniel added a comment.
Thank you for your response, @brennen! In T277362#6922054 <https://phabricator.wikimedia.org/T277362#6922054>, @brennen wrote: > 1. Deployers have no way to know in the moment that something is only a deprecation warning with no other consequences. If a warning isn't material to production health, it should probably either be labeled in a way that makes that extremely clear, or be sent to some channel that isn't surfaced where deployers are looking for signs of production breakage. In my mind, deprecation warnings should never be material to production health. They exist in order to warn //before// things break. So perhaps they should be channeled elsewhere. But we would have to make sure that they are still noticed, and bugs still get filed. They should definitely not be ignored or allowed to pile up. > 2. If there's ever a conversation about whether something might become a train blocker, RelEng would greatly appreciate if we were looped into the discussion by having it surfaced on the blocker task. Please see Deployments/Risky change template <https://wikitech.wikimedia.org/wiki/Deployments/Risky_change_template>. We can and will improve our documentation about this. (See T273802 <https://phabricator.wikimedia.org/T273802>.) Duly noted. We had a couple of such risky patches a while ago, around ParserCache. We did not think of this patch here as risky, precisely because it only introduced warnings, and did not break behavior. > 3. It is undeniably true that we sometimes halt the train on things which are "only" logspam. Partly this is because it's hard for us to tell the difference without developer input. Partly this is because halting the train is the only way we can get enough of them fixed to keep production logspam down to tolerable levels. I'm not complaining that it's broken, I'm thinking about ways to improve it. And there are certainly different kinds of "warnings" - e.g. a "notice" about accessing an undefined array key may have very serious implications, depending on how that value is being used. I'm trying to think of a better channel for things that should be fixed asap but are not a danger to the life site. Fixing deprecation warnings isn't nice to have, it should be high priority. But it's not UBN, and it should not block the train. Maybe a separate log channel would be the way to go. 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
