- Issue created by @quietone
- 🇺🇸United States cmlara
I believe this should be D.O. Customization not infra.
Updated title to reflect the decision was only for Core.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Is it? I thought all GitLab related things were under Infrastructure :-) I don't think this has anything to do with D.O beside the Credit & Committing box which will be phased out with GitLab.
- 🇺🇸United States cmlara
I thought all GitLab related things were under Infrastructure
The Merge Request GitLab message templates for Core can be set by any user with the GitLab Maintainer permission for the Core project (all full core committers), no need to involve anyone outside the Core project.
I did forget that there might be an on-commit web hook. Does that enforce a commit message format for core?
Adding the needs IS update tag for clarification on what is being targeted for change.
- 🇺🇸United States dww
I believe core committers still don’t use GitLab for merging MRs. They have their own local scripts and end up applying everything as a patch locally, running some pre-commit checks, and pushing the resulting commit.
Ideally, “the tooling” would make it easy to make these readable commit messages for everyone, not just core committers. The default commit message in the d.o issue UI is dutifully implementing what has been our convention for years, but it’s making out git histories really awful, hard Ti read and harder to use / understand. The goal of the policy issue was to get core to decide a new convention with the explicit hope that most / all of contrib would follow their lead.
Step 0 could be to modify the d.o issue hit message UI to stop injecting usernames at all.
Step 1 could be to fix it to use the[#xxxxx] $type: $title
convention
Step 2 could be figuring out how to implement this in GitLab with as much automation as possible
Step 3 could be to understand why core committers still have a patch-based workflow and see if we can unify that with GitLab workflow
…I’m not sure what queue is most appropriate, but I’m not sure it really matters. Maybe we’re not going to spend another minute on the d.o issue UI’s commit message tooling. Maybe this is entirely a GitLab configuration thing.
But I hope it can be fixed in a way that either makes life better for all of contrib, or at least is extremely easy to reuse across projects so contrib can trivially opt in.
Thanks!
-Derek - 🇺🇸United States drumm NY, US
I asked for this issue to be opened under the infrastructure project. Micromanaging where it is isn’t necessary until implementation, either project is fine.
As far as I know, the reasons core committers are not using GitLab’s merge UI are the commit message format, which this hopefully solves, and https://gitlab.com/gitlab-org/gitlab/-/issues/26902
Ideally we set up GitLab’s merge UI to do the right thing by default, and discard the commit message drafting from Drupal.org. GitLab’s commit message templates are documented at https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates....
The next step is to set up a contrib project with a template containing
%{co_authored_by}
and%{reviewed_by}
.If that is workable, we can make it the default for new projects, and bulk update projects that haven’t set their own template.
- 🇺🇸United States cmlara
If that is workable, we can make it the default for new projects, and bulk update projects that haven’t set their own template
We should probably obtain community maintainer consensus before such a push to existing projects?
The core issue was focused on core. The core team hopes that contrib would follow, no discussion was had with the community in general on it being pushed out as a default for all projects.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
You are not forced to do anything with it :-) you can just keep committing like you've always done. I also think already a lot of contrib maintainers aired their opinion on the core issue.