Disclaimer: I really appreciate all the work drupal core developers do. This is about suggesting ideas for the benefit of all.
Problem/Motivation
Since we moved to git, we have a lot more flexibility about how to accept changes for the project. Originally, on CVS, each maintainer was responsible for commit messages, merge strategies and tagging.
Now that we are using git, those aspects have changed, and now the responsibility is sometimes shared by authors.
Workflow
With Git, we can decide on how to include the changes into branches(instead of just use commit on CVS).
This is related to the workflow(s) we are using. Currently, we seem to be using two workflows:
- one for normal issues: Centralized, applying the patches manually(avoiding git-am when possible, see the attribution section too).
- and one for initiatives: Dictator and Lieutenants, merging from public initiative sandboxes.
It's OK to use more than one workflow, but we should use the same conventions for commit messages and merge strategy levels.
About the centralized workflow: it does not make sense to have merge commits(e.g. f356dc2), because there is no really original information in commits.
These merges are probably auto-generated when pull'ing before push, and in that case it makes sense to just rebase the changes(e.g. do git fetch, git rebase origin/8.x). In general it is a bad idea to make merges without reason.
About the lieutenants workflow:
- It does make sense to have merge commits from initiative sandboxes to upstream.
- Initiative sandboxes should not merge from upstream unless needed(code added upstream needed for the initiative), see references for details.
- Initiative owners should ensure they receive a clean history, see references for details.
References:
Commit messages
Historically, the drupal project has enforced coding standards, and I remember a lot of issues being marked to needs work because of empty spaces, or typos on documentation.
Also, a lot of the history of drupal core code embraces the commit messages handbook page.
So, it seems like as a community, we support the idea of paying attention to detail.
But, recently, mainly from initiative merges, we have included a lot of commits that do not conform with the commit messages handbook page.
It's not only about the attribution and issue linking, but instead about the contents of the commits, they include trivial changes such as 4a8adb2(those should be kept private when possible). Think i.e. is that commit really one that should be at the side of 0275068 where attribution is shared?
I have also noticed that some commit messages start with "- #nid" instead of "Issue #nid", I guess that's an old version of dreditor on a pusher maintainer?
So, we need to decide if we are going to use commit messages handbook page for all commits, or we just drop it in favor of any other convention(s). Please notice this includes commits merged from initiative sandboxes.
On drupal core issue queue, we usually have many people participating on one issue, so we usually want to make attribution for many people on one commit.
On CVS, we were forced to include attribution on the commit message, because there was no VCS supported way to do it.
Now with Git, we can use real attribution, but sadly only for one author and one commiter.
Some projects like the linux kernel or git itself, uses special strings at the end of the commit message for that propose, maybe we should consider using the same.
sdboyer also propossed another way using git notes.
Any solution we choose for this, we need to be consistent for every commit added upstream(also all commits coming form initiative merges).
See
🌱
[policy, no patch] Determine format for commit credit for individuals/organizations/customers
Needs review
for a possible implementation.
Tags
Git provides two types of tags: simple and annotated, the last one can also be gpg-signed.
Currently we are using simple tags.
Annotated gpg-signed tags are usually the recommended for real release tags, mainly for verification.
Should we start using gpg-signed annotated tags?
Proposed resolution
(description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch)
Discuss about the three topics to agree on conventions.
Remaining tasks
- Receive feedback about the three points
- Agree on conventions
- Public conventions as a handbook page on documentation.