The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
This is a followup issue to
- #2785891: The distinctions between modules, themes, and other subsystems are not relevant in MAINTAINERS.txt or the issue queue component field
- #2786145: Clarify how multiple maintainers share a role
It's also a small, reasonable step toward the ideas proposed in
- #2702321: Group core components into broad categories
- #2449085: Make "Component" a multi-value field, or allow sub-components
Also see: #2808123: Add a Testing framework component to MAINTAINERS.txt.
Views and Views UI are not maintained separately. They are maintained by a single team. The fact that the UI lives in a separate dependent module that can be turned off is an implementation detail, but it's not actually a relevant part of the governance.
As the only maintainer for Views who is not also a Views UI maintainer, I can freely say the distinction does not really make sense. :) I still am involved in Views UI issues, even if I'm not as comfortable with the code of Views UI as I am with Views itself. Plus, per #2786145: Clarify how multiple maintainers share a role, I and the rest of the team can agree that I won't be as directly responsible for UI code.
Proposed resolution
Combine Views and Views UI into a single listing in MAINTAINERS.txt, reflecting that there's a single Views subsystem with a unified team.
Don't change the issue queue (or at least not right now), until we decide what we want to do with metadata for what would be subcomponents-or-whatever as part of a different Drupal.org change.
Remaining tasks
Needs signoff from the other Views maintainers.
| Comment | File | Size | Author |
|---|---|---|---|
| views-single-component.patch | 587 bytes | xjm |
Comments
Comment #2
xjmComment #3
xjmComment #4
xjmComment #5
dawehnerI 200% agree with the idea of the issue. Its one system at least in regards of maintaining.
That patch is weird, isn't it? Doesn't it cause names to be listed multiple times under one component?
Comment #6
alexpottWe need all the maintainers +1 before doing this I think. Patch looks good ... @dawehner see the
--Comment #7
lendude+1, I definitely don't differentiate between the two when looking at issues.
Comment #8
tim.plunkettPersonally I do consider them separate when approaching bugs, since one is "just the UI" and the other is the API.
So for the issue queue, I would be hesitant to combine them.
But as far as MAINTAINERS.txt goes, I agree they're a single subsystem.
Comment #9
dawehnerPersonally people have a hard time to put issues into the right component from my experience anyway. Its often a bug which is related with both parts. Also people are confused, because most UI issues, is still code in the views module. The actual views_ui.module is relatively small.
Comment #10
damiankloip commentedI'm also fine with this being the same in MAINTAINERS.txt but agree with Tim, I think having the separate components is still useful. It is sometimes a really weak line between the two though...some of that stuff is pretty coupled. So I would not be too upset if they were merged either.
Comment #11
jibranI'm not a sub-system maintainer but I have worked quite a bit in views issue queue so I think I can also share some thoughts on this. IMO views and views_ui are not decoupled like field and field_ui. After moving views to core we move all the field and entity specific views code to respective modules or to the Core and that leads into some issue discovery problems/confusion like
core_field_views_data, all the converted entity listing pages bugs belong to respective entity component not to the views,\Drupal\views\Plugin\EntityReferenceSelection\ViewsSelectionbugs belong to entity system(entity_reference) butentity_reference_displaybugs belong to the views.Some of these problems can be solved by adding a sub-component field to issue tracker but that's a whole different story. As per the views_ui there are not a lot of APIs in play here. We have some front-end facing stuff in the views_ui and the way the views and the views_ui are written this front-end facing code is quite complex and it interacts a lot with the each other which makes it very hard to distinguish on the bases of the component. Even inside the views plugin we are using views_ui functions i.e views field plugin provided by the views field view module calls the function
views_ui_build_form_urlin::buildOptionsForm. In that sense merge those will not be a bad idea but as I mentioned before the discovery of issues are not so great within the issue queue and merging these would bring more confusion so from my point of view it's a big -1 so putting it back to NW for more discussion.Comment #12
tim.plunkettSorry I shouldn't have brought up the issue queue component part, the IS says:
Since this is just about MAINTAINERS.txt and all of the maintainers have signed off, setting to RTBC
Comment #13
xjmThanks @jibran. #2449085: Make "Component" a multi-value field, or allow sub-components is the place where we can explore how we represent the components in the issue queue.
Comment #14
jibranLet's make the title clear then.
Comment #15
xjmSure, thanks @jibran. I still believe the original title though. :)
Comment #16
alexpottOne thought is should the Views section detail that maintainers are maintaining both the views module and the views_ui module? Somewhere we need to detail what exactly is a part of each subsystem - especially if we moving away from a 1 to 1 relationship with modules and subsystems. But this shouldn't hold us back here.
Committed and pushed 7cc1c08 to 8.3.x and 10a4c63 to 8.2.x. Thanks!
Comment #19
dawehnerWell conceptually I'd rather split it up by by "views" and "views UI" vs. "views.module" and "views UI" module, but that would probably confuse everyone.