In T212482#8293384, @Ottomata wrote:

BTW, The reason we are moving to preferring a single entity change model rather than multiple models for each change, is that generally, a consumer of these events is trying to keep track of what is happening to the entity.

In T212482#8290286, @Ottomata wrote:

I'd suggest a more unified data model though, something more like:
afterPageDeleted( PageChangeEvent $event )
where PageChangeEvent can be used for the param to many of the page change hooks.

In T212482#8290304, @Ottomata wrote:

FWIW, I find 'filter' a strange name for the type of hook that can mutate state. I'd expect a filter to be a boolean filter operation. I guess yall are saying it can cancel the calling of future callbacks, which is like a filter...but mutating state in a filter sounds weird :)

@Jdlrobson just pointed me to T214000: Evaluate difficulty of porting PCS summary logic to PHP

Blocker: T319282: Language variant conversion broken for page/html endpoints on RESTBase. Should be fixabed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/838094

In T314231#8247004, @tstarling wrote:

It's hard to find anything that really needs to be in overrideConfig or finalSetup. In the PHPUnit tests, config adjustment is done after setup completes, which mostly seems to work as long as you do a service reset. But a lot of instances of config adjustment could be replaced by setting a property in a service.

The problem I'm trying to solve here is that MaintenanceRunner can't instantiate a MaintenanceObject defined by an extension before config has been loaded and extensions have been initialized. If we try to do that before instantiating the Maintenance object, then the call to finalSetup() on the maintenance script would only happen after config loading is complete, and config can no longer safely be changed.

In T308017#8169868, @Ottomata wrote:

However, in the future, we'd like to support 'rendered' content in streams. It'd be nice if we could have a generic enough model to support that.

@Jdforrester-WMF My understanding is that when we add a new extension A that depends on existing extension B, we expect people to know that in the CI config, thy must declare not just the fact that A depends on B, but also declare that now, B depends on A, becasue A can break B. This seems non-obvious, and looking at the config we have, it seems like people get this wrong more ofthen than they get it right.

In T318107#8246434, @daniel wrote:

Point in case: Last week, a patch I worked on for VisualEditor broke the DiscussionTools extension. The issue was not noticed in CI, because the VisualEditor repo doesn't run DiscussionTools tests.

Yes. The person merging the ultra-world-breaky code like this should have known it was super-risky. This is why you defer to the relevant team.

In T318107#8246555, @Jdforrester-WMF wrote:

By the way: conversely, running VisualEditor's tests for every change to DiscussionTools is probably redundant. A change to DT is not going to break VE. We should be smarter about what "depends" means in the context of testing.

That's literally what "depends" means. If you want to add a secondary concept of "half-dependency" we could add that.

Point in case: Last week, a patch I wrote for VisualEditor broke the DiscussionTools extension. The issue was not noticed in CI, because the VisualEditor repo doesn't run DiscussionTools tests.

In T318107#8246331, @Jdforrester-WMF wrote:

This idea would mean creating a cyclical dependency in all tests, which isn't generally appropriate, and making each downstream user's hacks a critical blocking dependency, which is almost never appropriate.

Note that in the context of CI, "dependencies" go both ways. See T318107: Zuul: Interpret extension dependencies as mutual.

Thank you for catching this!

In T314544#8241737, @kostajh wrote:

@daniel is this something urgent, and/or something you need our team's help with?

@Tgr I would propose we move this off of the current sprint if we are not working on it in the next week.

In T308364#8211278, @PatchDemoBot wrote:

Test wiki created on Patch demo by DKinzler (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d4396b72c3/w

(oops, closed the wrong ticket)