[Meta] Tasks to deprecate both Aggregator and our dependency on Laminas Feed

Looks the related could be closed now

I suspect that #2940739: Project messaging channel in core initiative will end up recreating the Aggregator module in core. I would like to see whatever is created for that initiative made reusable for custom feeds. Feeds in core would not replace Aggregator because Feeds does not provide item and source entity types. Aggregator has usability issues, but if they were addressed, I think it would be used more widely. Now that we have a compelling use case, Aggregator deserves a second look.

We now have 'lifecycle' in .info.yml files, so this is unblocked.

However, noting #5 - if we do actually want to display RSS feeds in core, then we shouldn't rebuild aggregator.

Step 1.

Besides the current patch needing to be against 9.4.x-dev and having no lifecycle_link, the procedure for deprecating/removing Core modules, currently is roughly like this:

- Move all tests related to the module to be deprecated/removed into both the module directory and namespace.
- Copy module to its own Contrib module.
- Move open issues concerning module from the core queue to the above Contrib queue
- Deprecate module in 9.4.x
- Delete module in 10.0.x

Seeing that deprecating/removing this module also includes removing some core dependencies, the above might be more elaborate.
I'll leave that to Bigger Brains.

For now I've opened #3264120: Remove aggregator module and our dependency on Laminas Feed for a straight up removal of core/modules/aggregator directory and laminas/* dependencies to see what breaks and needs to be moved/fixed in #3264122: Move all non migration aggregator tests to the module in preparation of removal in d10

Postponing on (at least) #3264122: Move all non migration aggregator tests to the module in preparation of removal in d10

Seeing that #3263654: Move all HAL tests to the module in preparation of removal in D10 will move a lot (8 in fact) of tests away from the aggregator module, it makes sense to also postpone moving this module to Contrib on the commit of that issue.

Not sure why we need to migrate the data? There won't be a replacement data structure in core, people will either need to uninstall the module or switch to the contrib module at the same time as updating core, and then their data will continue to work (and if not it will be the responsibility of the contrib module if that made changes?)

As long as aggregator's migration path from Drupal 6/7 is self-contained, it should be fine to move that to contrib - it'll all have the same namespaces etc. The issue we're likely to hit though is the core test database fixture for migrate having aggregator data in it. I think we will probably want to just leave the aggregator data in the core fixture to keep things simple, and then the fixture will eventually go when we move the d6/d7 migrations to contrib.

Before the aggregator module as-is can be moved to Contrib (which is around the same time it can be deprecated), the moving of the migrate related aggregator tests also has to be committed.

PP+1 on #3265424: Move migrate related aggregator tests to the module in preparation of removal in d10.

#3263654: Move all HAL tests to the module in preparation of removal in D10 was committed.

I put the migration issue as a blocker as well.

I've (tentatively) put the help topics move #3267052: Move aggregator help topics to aggregator module as a blocker as well.

Updating remaining tasks with the steps in the module deprecation policy. Removing postponed from the title because there may be steps that can we worked on, or created, while waiting on the issues in step 1 to be finished.

Fix typo

Ad removal issue

Add #3267274: Use aggregator fixture instead of migrate_drupal fixture in d6/MigrateBlockTest

Add deprecation issue.

Add #3267508: Use aggregator fixture in migrate Functional tests

I've pushed the code to the aggregator contributed project. I'll need to add a composer.json but I'll do that once we're good to go so I can keep pushing from the subtree split

The needed lifecycle_link is to point to a new section on the recommendation page, https://www.drupal.org/node/3223395#s-aggregator. And the CR needs to include that link as well.

@quiteone

The needed lifecycle_link is to point to a new section on the recommendation page, https://www.drupal.org/node/3223395#s-aggregator. And the CR needs to include that link as well.

Right on both accounts, but it seems, like me, and because of me, you're tricked by (the most part of) the issue title and the MR (BTW against 9.3) in this issue.
This is the [Meta], which means the Big Brains hang out in here, and the grunt work is done in the child issues. For the actual deprecation that's #3267458: Deprecate aggregator module in Drupal 9.4. I'll add the CR and correct lifecycle_link in the MR over there.

Again: Sorry for causing confusion by blindly updating the MR in here, instead of the actual [DoStuffHere] issue and starting this whole derailment...

@Spokje, thanks for the explanation. I did think it was odd having an MR in this Meta but I didn't stop to look further. And now that I do I see that I opened #3267458: Deprecate aggregator module in Drupal 9.4 two weeks ago. Feels like too many irons in the fire...

Opened #3272246: Ensure that aggregator doesn't get special core treatment against project_composer, and #3272247: Stable release against aggregator.

Last step is to move the issues across - still @todo.

Moving issues to contrib queue here: #3272651: Move core issues for Aggregator module from the core queue to the contrib module

All child issues are done and summary tasks are completed