Deprecations "subsystem" and maintainers

I think this would make total sense. Deprecations are now a super integral part of the core process and upgrades are still a lot of work to support from the tooling side. I don't know if we must have a subsystem to put in a gate, but that would probably be the most sensible approach to it indeed.

I agree with this except that I don't think deprecations is exactly the right scope. It feels more like developer tooling (which could then also cover gitlab integration which is currently shoved under phpunit and coincidentally bbrala also works on).

Developer tooling was something I also thought of as well. But I was afraid it would be too broad for the initial discussion. So I agree that's better and gives a bigger purpose

I think this is more of a topic maintainer role.

I should have elaborated in my previous comment -- the topic maintainer roles correspond to the Drupal core gates. (Usability, accessibility, documentation, testing, etc.)

Since we want to add something like an "Upgrade path and automation gate" (better names may exist), it makes sense to create a topic maintainer group for that.

Retitling the issue and updating the IS accordingly.

Maybe we could call it simply the "Upgrade topic maintainers" and "Upgrade gate"? The upgrade path itself is a release management focus area, but the improvements to the D9 and D10 upgrade paths would not have been possible without the support of people informally acting as maintainers of these essential tools and processes to date.

@Gábor Hojtsy is another person who does a lot of work related to the major upgrade path; maybe he should also be in this group?

Upgrade topic maintainers

For me this is tricky because it sounds like it should include database update system et al, which I wouldn't wish on any living human being but is also a very different area.

Matt, Björn and myself do a bunch of work in this area, but the technical (API) parts are not my forte, its theirs :) Sounds good IMHO to add as a topic. Hopefully we can find a good name :)

I think the responsibilities all evolve around code upgrade tooling and what core changes need to comform to, to make it feasible to build those tools. So "Tooling for code upgrades topic"? I think the naming could be adjusted later, it would be great to establish this in our governance though to embed those working on the tools in the process.

@Gábor Hojtsy Do you mean an outline like in here?
https://www.drupal.org/about/core/policies/core-change-policies/core-gat... →

Can this start with a tag for issues that introduce deprecations and a process to create an issue in Rector or Drupal PHPStan for follow up?

From my understanding after discussing briefly there are a few concerns:
1. Make sure change records have a BC snippet for module maintainers
2. Ensure that deprecations are properly triggered
3. Catch runtime deprecations for further review
4. Ensure that phpstan-drupal and or drupal-rector can fix / catch deprecations

What about while these details are hashed out we start with a non-blocking tag for `Needs Developer Tooling` or something similar.
Then once we start tagging issues we can evaluate scope and see what needs to be documented vs addressed before merging.

I'm not trying to volunteer anyone, I am trying to parse out above, feel free to correct anything I state below.
And to prevent repeating I'll define the Developer Tooling Team (DTT) as the following people for now.
Gábor Hojtsy
mglaman
bbrala

Would a responsibilities list look something like this for a first pass?

TASK: Tagging issues for review by DTT

• Community
• Needs Review Issue Queue
• Committers

TASK: Triaging tagged issues

• Developer Tooling Team

TASK: Creating followup issues in phpstan-drupal and or drupal-rector

• Community
• Developer Tooling Team

Maintaining phpstan-drupal and or drupal-rector

• Community
• Developer Tooling Team

As an example I've tagged 📌 Test that all form elements have a title for accessibility Needs work

That also obviously allows: https://www.drupal.org/project/issues/search?issue_tags=Needs%20Develope... →

Then a first step would be to create an issue like this: https://github.com/mglaman/phpstan-drupal/issues/748
Maybe a template can be put in the project for the details that Matt would like to see.

For now I would also say only the members of the DTT should remove the tag until we establish guidelines.

We should combine PHPCS with Rector.

For example, when running the Rector rule to convert annotations to attributes, the resulting PHP attribute is all on one line and the classes aren't imported. That's because Rector can't do class imports (it can only modify the node it found AFAIK) -- I don't know whether we could improve its output to do linebreaks.

But the resulting code can be improved by then running it throuh PHPCS & PHPCBF. In the case of converting annotations to attributes, the Drupal.Classes.FullyQualifiedNamespace.UseStatementMissing sniff will fix the classes at least.

So Rector rules should come with a list of the specific PHPCS sniffs that are needed to correctly reformat the fixed code, and our tooling should run Rector AND PHPCBF with those sniffs.

@joachim, thanks for your insight, I think that would be certainly helpful, and I think bbrala has been experimenting with core rewrites.

I think it's slightly off topic for this thread though as this thread is more about providing support to the team behind rector and phpstan so they can provide insight and be notified of changes that require rector / phpstan updates before they land.

The current process requires a lot of effort on their part to remain informed and they are always chasing. Ideally we can be more proactive to help with such important tools for keeping contrib up to date.

Possibly relevant related issue.

Me, catch, gabor and mglaman just talked about this in Barcelona.

We considered the different possible names eventually basing is on what would our main goals be.

The goal of the topic would evolve around developer tooling with the name Developer Tooling. This will manage phpstan and possibly also rector. And in a followup create a gate on making sure that we (will) handle deprecations and other possible updates on that. This could also compose of some work being done in the gitlab side of things for core which is something I've been involved with anyways.

The consensus we had is that Developement Tooling is the best way to go since that would contain all the right things without suggesting subsystems like database upgrades and such.

I think comment #13 is pretty good summary on what the initial workflow would look like.

Gabor, catch, mglaman and me think this is the right way forward.

Retitled for that scope then. Should we open an MR in an another issue or conver this to a core issue?

+1 to developer tooling from me.

+1 for developer tooling.

For example, I foresee Drupal core starting to retain specific PHPStan rules rather than adding them all only to phpstan-drupal. Or maybe the Rector rules as well. This group can then help manage these related issues.