Problem/Motivation
Drupal 6 support is going to be dropped this month.
Core's component list is unwieldy to handle, for at least three reasons:
1. Stale components that are no longer used/exist
2. Components that are hard to differentiate - batch system vs. form system.
3. Sheer number of components - i.e. one per module.
#3 is not the focus of this issue, we could tackle that in another issue but it'll be difficult. I think we could fix #1 and #2 quite easily though.
Proposed resolution
Go through the existing component list and trim it down.
There's no good way to collaborate on this - the list only exists as a multi-value text field.
So went for google docs with suggestions:
https://docs.google.com/document/d/1XdC00nJFPEHcdK6JVu0ijkJO8MXkljoC1PnT...
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#2 | components.txt | 1.96 KB | catch |
Comments
Comment #2
catchCurrent list as a .txt because it's annoying to parse it out of the issue creation form options markup...
Comment #3
xjmComment #5
xjmSo 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:
Edit: Moving my notes to the postponed issue to not confuse the discussion.
Comment #6
xjmI 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
Comment #7
catchFor straight renames on a 1-1 basis a bulk update sounds useful.
Some components definitely do not need a bulk update, for example the lock component:
https://www.drupal.org/project/issues/search/drupal?project_issue_follow...
15 issues
Two of them are about database deadlocks.
One of them is about blocks.
5 were updated in the past 12 months.
Two of those are the misclassified ones.
Just a validation error on those issues is preferable to moving them all the base system for me.
Comment #8
xjmTo start, I deleted the following legacy and previously renamed core components that do not exist for Drupal 8 or 7:
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:
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. :)
Comment #9
Wim LeersWow,
story.module
,page.module
,blogapi.module
. How times have changed!Comment #10
dawehnerMade a couple of comments on the google doc.
Comment #11
xjmDeleted another old stray... upload.module.
Comment #13
xjmComment #14
xjmComment #15
xjm#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.
Comment #16
xjmAnd 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.
Comment #17
Gábor HojtsyRe comment #8:
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.
Comment #18
xjmAnother 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).
Comment #19
YesCT CreditAttribution: YesCT commentedI 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.
Comment #20
YesCT CreditAttribution: YesCT commented@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.
Comment #21
pfrenssenWe 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 :)
Comment #22
pfrenssenI think this is what you are looking for: #2102233: Automatically lock issues a year after they're closed.
Comment #23
xjmComment #24
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedComment #25
frobI haven't seen it listed here yet so I will make one more suggestion.
Can we easily just alphabetize the list?
Comment #26
frobI added #2797899: Alphabetize core components select list as a child issue.
Comment #28
cilefen CreditAttribution: cilefen commentedI related #2864277: Make the Component list searchable (or easier to choose from).
Comment #30
xjmMile23 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.
Comment #36
dww+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.
Comment #37
quietone CreditAttribution: quietone as a volunteer commentedI'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
Comment #43
prabhu9484 CreditAttribution: prabhu9484 at gai Technologies Pvt Ltd commentedProblem description #3 - Seems to be related to https://www.drupal.org/project/drupal/issues/3339890
Comment #45
quietone CreditAttribution: quietone as a volunteer commentedThere 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.