Plan for statistics in contrib

I'm seeing a 404 error on https://drupal.org/project/statistics. Is-it normal ?

@Kgaut: See #3341091-8: [11.x] [Meta] Tasks to remove Statistics → .

@Kgaut the "statistics" project name is currently reserved, we have asked the drupal.org administrators if this restriction can be removed so it can be used for the module in contrib.

Details on 🐛 Statistics path is no longer reserved RTBC .

The proposed resolution is missing coordinating with the Drupal Association for packages.drupal.org adjustments, which needs to be done any time a module or theme moves into or out of core with the same name. Picking a different name for the contrib version would make this go a lot more smoothly for Composer.

If a new name can't be used, a new issue like #3308347: Ensure that ckeditor does not get special core treatment → needs to be created, and updated when the module is ready to be installed on its own. There are still risks, see 🐛 Incorrect version of CKEditor being parsed from info.yml files Active and its related issues.

Reserving the name via project_issue module wasn't intended, but I'm glad it was, since these steps were being skipped. I'll look at getting every other core component's name reserved.

Just noting that Step 4 in this issue is covered by Step 5 in the Meta to remove statistics. 📌 [11.x] [Meta] Tasks to remove Statistics Postponed

@drumm, I think you have identified a mistake in the documented process for removing an extension. Currently, the step to create an issue like #3308347: Ensure that ckeditor does not get special core treatment → is in the set of steps to do for removal, not for deprecation.

Adding the deprecation issue because that can only be completed once there is a stable release of statistics in contrib.

somehow https://www.drupal.org/project/statistics → still 404

The packing issue is 📌 Ensure that Statistics does not get special core treatment Active

If https://www.drupal.org/project/statistics → is not set up in the next day or two, I should re-reserve it, so it isn't taken by another project.

If a different name could be used, then 📌 Ensure that Statistics does not get special core treatment Active would not be needed and we avoid any unexpected Composer behavior.

@drumm : I am still not able to create the project node, see attached image.

The project name, “Statistics” also needs to be unique for autocomplete fields, like the Project field in the issue update form on this page. You could call it something like “Statistics from core.” I did go ahead and delete the conflicting project, since it was a sandbox with no code, that was a bit spammy. So the “Statistics” name is also free now.

Iris alive https://www.drupal.org/project/statistics →

So the last issue unblocked 📌 Deprecate the Statistics module Postponed

@fgm, thanks for taking on maintainership of statistics in contrib. :-)

The next step for deprecating statistics in core is to have a stable release of the contrib project. @fgm, do you have time to do that?

If needed there are instructions at Create the contrib project with a stable release → .

Thanks.

@quietone yes, that's my main goal for the DrupalCamp Rennes code sprint this week. I've set up a discussion with camp participants to have a variety of points of view to guide the plan.

After the discussion at DrupalCamp Rennes, the contrib plan is now at 🌱 Plan for Statistics 1.x Active .

Hello the statistics team,
Will the new module set some more details as dates, referrers?
Where can I read the specifications?
Regards

@frondeau : please follow up on 🌱 Plan for Statistics 1.x Active . The future is now being written so you can be part of it. If you are attending DrupalCamp Rennes, join us in the second contribution room.

@quietone the current HEAD is now passing tests (except warnings on cspell), so it seems to be ready for 1.0.0, or at least 1.0.0-alpha1.

@vanessakovalsky and @hellosct1 also did a lot of triage on the remaining core issues at DrupalCamp Rennes.

@fgm, that is great news! There is one more thing needed before we can tag a core release with a deprecated statistics module and that is a stable release of the contrib module. Can you do that?

IMHO the module is ready to at least tag a 1.0.0-alpha1, but I'm a bit worried of tagging the 1.0.0 proper without third party review. Think I should do it nonetheless ? (and I fixed the cspell issues too) Build is broken by #3437434: Composer (next major) no longer works after 11.x updated to Symfony 7 → but passed before that.