Deprecate Tracker module in D10 and move to contrib in D11

Can everything in tracker be done by views?
If so, remove it.

Tracker is a nice feature out of the box, and a nice candidate for denormalization. It has very few bugs and is not a maintenance burden. Let's keep it.

I agree with Damien. The denormalization can't be handled by views yet.

Could we postpone this until the #286665: SEE ISSUE #1805996 -- Moving Views into Drupal Core starts to materialize (notice what I did there?)? The tracker feature requests includes an API change in #366511: Decouple Comment module from Tracker and improvements that seem to be best handled by Views and #28480: Create generalized relationship module.

Re: denormalization
@Damien: Would you please update this issue with respect to #1497374: Switch from Field-based storage to Entity-based storage and your London Core Conversation on Document Oriented Storage where you spoke about how MV (see also Materialization Plugin for Views) could be consistently used for denormalization in relational databases?

Accidental tag change. Sorry, sun :)

Reopening now that #1805996: [META] Views in Drupal Core is committed and #1801726: EntityFieldQuery v2 includes optimizations for table joins.

Perhaps a combination of #1803064: Horizontal extensibility of Fields: introduce the concept of behavior plugins and entity storage backends through #1497374: Switch from Field-based storage to Entity-based storage would offer potential for denormalization.

Also, I'm not sure how #1801304: Add Entity reference field may be related, but linking for good measure.

Edit: also meant to link to #1740492: Implement a default entity views data handler.

Instead of remobing tracker maybe either changing it or replacing it with a glorified flag module?

then the tracker view can be a ... view of a specific type of flag (which can be added by default as an action...).

Tracker also provides two tables for denormalization and views integration for them. To replace that with views would mean the materialized views views (sic) integration being fixed up and added to core.

Yeah, I'd prefer to do #1941830: Convert tracker listings to a view for D8, and then we could consider removing Tracker and ilk in D9 in favor of an "MV in core" solution. (I swear we have a core issue for that somewhere, but I can't find it atm.)

Maybe this issue needs a different title? Discussion tends towards how to reproduce Tracker with Views.

The alternative may be to take the module in the opposite direction.

Tracker is a special flag. Making it more generic so that it can be used for other flagging needs (or replacing with flag module) may introduce useful functionality in core.

Some rough usage data: #2867597: Top Drupal 7 and Drupal 8 core sub-modules

Adding the "idea template" to the issue summary. Short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thank you!

There is a replacement module in contrib already: https://www.drupal.org/project/trackerlite

Maybe instead of conversion tracker to views we can add this views to comment module?
@catch pointed that tracker makes no sense without comment & history modules in #366511-94: Decouple Comment module from Tracker

I bet it was a typo

Revisiting #1261120-3: Deprecate Tracker module in D10 and move to contrib in D11. We added denormalisation to tracker in #105639: Tracker performance improvements, but have got no closer to making that generic. The closest is https://www.drupal.org/project/mv which is abandoned. Generic denormalisation for views and entity queries would still be nice to have, but tracker isn't helping us get there at all.

Meanwhile there are issues like #2875033: Optimize joins and table selection in SQL entity query implementation which would improve performance of our existing queries.

#1941830: Convert tracker listings to a view has been open for eight years, tracker is still defining routes manually and building tables in controllers - it's a very bad example of how to build an entity listing.

For people that need a similar feature, you can build exactly the same feature in views (without the denormalization) using only core, or they could install the contrib project, or build slightly different listings of user content/comments.

Based on all the discussion above and in #3158669: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version, I agree tracker would be good to move to contrib. It is among the modules that provide a one-off feature that does not have an ecosystem (stuff built on top of it) in contrib and does not serve as a base service that contribs could share an implementation of.

What is the next step to deprecate tracker?

@andypost we'd need someone to create a contrib project for it, and tag a release.

Should also have a patch that removes it to check if there's any test coverage that depends on it being installed.

I have created an issue #3261452: [11.x] Remove tracker module from core to deprecate and try to remove the module

I have created a new contributed project for the tracker module https://www.drupal.org/project/tracker and pushed the codebase into 1.0.x branch
@andypost I have added you as a maintainer of it

We should set up a date to move tracker bugs from core to the tracker module queue.

Since this has been approved and there's a contrib maintainer and project (thanks naveenvalecha and andypost!), I think this is.. RTBC?

This all sounds good to me. +1 for removing and +1 for RTBC to this task.

Maybe I missed it, but if this is just the "Idea" that's now RTBC, I only see #3261452: [11.x] Remove tracker module from core for the D10 removal issue. Should we convert this issue into the D9-mark-deprecated issue, or spin off a child issue for that?

We have a separate issue for d9 deprecation https://www.drupal.org/project/drupal/issues/3261679

We'll have to update the scope of this to be for D10 deprecation and D11 removal, but we can mark the Idea issue fixed. :)