[Plan] Update core components

So I'm in the process of writing queries to prepare major triage sessions with both themeand entity/field system maintainers, which reminded me of this issue.

I think we should consider all of the following:

• Remove all components that do not exist in D7 or D8
• D.o issue for restricting component list by the version
• Policy/governance issue to group components into broad top-level categories (postponed on the removal issue above, because noise)
• D.o issue for optional subcomponents (these are the current components, so that e.g. emma.maria can look only for Bartik issues, but Cottser can find all issues for all themes)
• D.o issue to populate the top-level components
• D.o issue to allow multiple components

Edit: Moving my notes to the postponed issue to not confuse the discussion.

I posted #2702321: Group core components into broad categories and moved my broad grouping notes to there.

I left some comments on the gdoc. I think we should start by just deleting the components that do not exist in D7 or D8; I don't care if outdated issues lose their component data on update and that does not require anything but a committer updating the core project node. Anything that involves renaming components requires a bulk update from infra as well, because they are just stored as plain strings, not references or IDs. I made that mistake once in the past which is why it is currently "node system" instead of "node.module." :P

To start, I deleted the following legacy and previously renamed core components that do not exist for Drupal 8 or 7:

1. archive.module
2. blogapi.module
3. drupal.module
4. page.module
5. story.module
6. throttle.module
7. translation.module
8. translation_entity.module
9. watchdog.module

If issues filed against these components get updated, they'll have to pick a new component. (Edit: and there is a reasonable chance they'll be accidentally moved to the AJAX system.) ;)

Edit:

Just a validation error on those issues is preferable to moving them all the base system for me.

AFAIK there is no validation error; just it defaults to the first thing in the list. rfay patiently moved issues out of AJAX system all the time because of this. :)

Wow, story.module, page.module, blogapi.module. How times have changed!

Made a couple of comments on the google doc.

Deleted another old stray... upload.module.

#2785891: The distinctions between modules, themes, and other subsystems are not relevant in MAINTAINERS.txt or the issue queue component field is another actionable step here.

And after #2785891: The distinctions between modules, themes, and other subsystems are not relevant in MAINTAINERS.txt or the issue queue component field I'm going to start filing specific governance issues for components that can be combined, either getting the signoff of the relevant subsystem maintainers or just making the change in case of subsystems without active maintainers.

Re comment #8:

To start, I deleted the following legacy and previously renamed core components that do not exist for Drupal 8 or 7:

1. archive.module
2. blogapi.module
3. drupal.module
4. page.module
5. story.module
6. throttle.module
7. translation.module
8. translation_entity.module
9. watchdog.module

If issues filed against these components get updated, they'll have to pick a new component. (Edit: and there is a reasonable chance they'll be accidentally moved to the AJAX system.) ;)

Edit:

Just a validation error on those issues is preferable to moving them all the base system for me.
AFAIK there is no validation error; just it defaults to the first thing in the list. rfay patiently moved issues out of AJAX system all the time because of this. :)

I don't think we can depend on rfay to fix our metadata and even rfay cannot fix it if an issue is/was with upload.module and then it can only be moved to base system.

Drupal 5 vs. Drupal 6 vs. 7 vs. 8 has different set of modules, module names and components that could apply. Given that components are cross-version I don't agree that its a good solution to remove components altogether, because then any issue edited for an older Drupal release (to fix a tag, testbot glitch or who knows what) would mess up our issue metadata. Given the sizable difference between Drupal 7 and 8 also, the component list could never get appropriate enough for any issue at hand.

I think even a simple JS to make core components dependent on the version field would go a long way. Even if no server-side implementation to back it up, it would only allow people who really want to do incorrect combinations of version - component to pick an incorrect one. Drupal 8 would not have the overlay module, blog module, etc. while Drupal 7 would not offer you Classy, responsive images, menu_link_content and inline form errors among other things. While the issue submission/editing UI would show a version-appropriate set of components, the search UIs would still show all the components, but that is the only way one could find issues with upload module.

I don't see why we need to possibly mess up our history to fix a forward going problem that even with removing some components cannot be resolved satisfactorily. We need to make components conditional on version numbers somehow anyway to make it clear for Drupal 7 and 8 for several years to come.

Another thing I think would help would be to "lock" metadata for very old, closed issues since reopening them causes a lot of problems. We should be able to comment and provide related issues etc. but not rewrite history of the fields (either accidentally through unexpected allowed value changes or because someone doesn't know the best practice to create a new issue).

I agree #17 sounds nice: having different components for different versions, and not removing historical data. But I see how that would be blocked on DA resources, and sometimes we are looking to see what we can do without DA resources.

@xjm re #18, there are a lot of (old) (closed) (duplicate) issues about closing old issues https://www.google.com/search?q=automatically+close+old+issues+site%3Adr... I'm not sure if tagging them might help consolidate the ideas from them? or what the current canonical "lock old issue" issue is.

We should be clear about the terminology :) "Locking" an old (closed) issue is different from "closing" an old (open) issue. I was very confused about the idea of "closing" old issues :)

I think this is what you are looking for: #2102233: Automatically lock issues a year after they're closed.

I haven't seen it listed here yet so I will make one more suggestion.

Can we easily just alphabetize the list?

I added #2797899: Alphabetize core components select list as a child issue.

I related #2864277: Make the Component list searchable (or easier to choose from).

Mile23 raised that we were using simpletest.module for phpunit for awhile. phpunit got added as its own component but Mile23 suggested a more generic "testing" component. I'd suggest changing that to "Automated testing" since "Testing" would get misused for test issues, hello world, etc.

+1 to #30. Since simpletest has now moved to contrib, we're left with only 'phpunit' as a legit component for all test plumbing / infrastructure. run-tests.sh should die, but until it does, seems like we need somewhere for issues related to it to be classified. So we should probably rename 'phpunit' to a more generic 'testing system' or 'automated testing system' or whatever.

I've been working on a Bug Smash Initiative task that is to move simpletest.module issues to the Simpletest module. As I read them I realized that some needed to remain in core but then I didn't know which component, as it wasn't about phpunit. I asked in #bugsmash and dww said to use 'phpunit', as it was the only component for 'testing' issues. That was a surprise.

The component list is hard enough to use as is, let's remove unexpected usages like phpunit for automatic testing issues. Or, given that this issue is 4 years old, how about a link to some docs like there is for 'Priority' and 'Status'.

+1 to #30

Problem description #3 - Seems to be related to https://www.drupal.org/project/drupal/issues/3339890

There is still work to do here but I think it best to move it to a new issue. I checked with catch about this and he agreed that this can be closed and work continue in the next issue. I am marking it fixed because it did complete a clean up phase.

The next one is #3385864: [Plan] Simplify core component list.