Tentatively CC'ing some people to get this task routed to the correct place. I'm sorry for having brought out this task a bit too late - all changes should be pretty easy to review, though.

In T234058#5532537, @Krinkle wrote:

@Krinkle edited projects, added Platform Team Workboards (Clinic Duty Team) ; removed Platform Engineering

That's currently a very good way to get a task lost, as the inbox on Platform Team Workboards (Clinic Duty Team) is currently a dumping ground that no one looks at regularly (we're talking about changing that). Daimona was correct to put it into the Platform Engineering inbox, that's where we'll actually see incoming tasks to route them properly.

Thanks, I vaguely recall hearing the other way around, my bad. I'll try to remember :)

One concern I have with all three of the patches is that you don't seem to be writing to the same deprecation log that wfDeprecated() writes to. Is that intentional? Do we care?

Other than that, they seem mostly ok at a quick read-through.

In T234058#5534966, @Anomie wrote:

One concern I have with all three of the patches is that you don't seem to be writing to the same deprecation log that wfDeprecated() writes to. Is that intentional? Do we care?

Yes, it's intentional. AFAIK, wfDeprecated is mostly for deprecated methods and other code paths which are part of the public interface. Deprecating filter syntax is a bit special, though. Is there an alternative?

Yeah, wfDeprecated() is probably not right for deprecations of features in user-generated content. But by the same token any server-side logging doesn't really reach the right audience, as what you really want to do is somehow inform the users who write the filters. Server-side logging helps developers see whether it's safe to move ahead with the removal, but (unless the developers go fix it themselves or manually prepare reports for the users) doesn't actually get the filters fixed.

In T234058#5535000, @Anomie wrote:

Yeah, wfDeprecated() is probably not right for deprecations of features in user-generated content. But by the same token any server-side logging doesn't really reach the right audience, as what you really want to do is somehow inform the users who write the filters. Server-side logging helps developers see whether it's safe to move ahead with the removal, but (unless the developers go fix it themselves or manually prepare reports for the users) doesn't actually get the filters fixed.

Yeah, I know... For WMF wikis we have Tech News, but for external consumers I'm not aware of anything similar. I just hoped that devs would notice the messages (they're pretty spammy), and inform people and/or edit the filter by themselves.

@mobrovac Thanks! Since we ended up being a bit late for the 1.34 release, I've backported everything to REL1_34 (one, two, three). Could CPT please take a final look, so that we can close this? Thanks again!

Thank you, @Daimona for the backports (I managed to forget to leave a comment about it being needed given the messages in the code). All three patches have been merged into REL1_34 now!