Hi Chris,

This seems like a good proposal to alleviate some of the pain around releases.

Some observations/questions.

1. Introducing additional tags will eat into precious real estate. This will be a problem for some changes and developers.
2. In the transition period, the proposal has the potential to “pollute” the history
3. The proposal will add more work for patches cherry-picked from other projects e.g. libfdt
4. How do we handle scenarios where platforms donot want to switch to this policy?

I can see how #1 might be of concern to many, but we will have to implement some policy to see how many commits really fall in this category.

-Varun

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A
Sent: Thursday, February 11, 2021 5:59 AM
To: tf-a@lists.trustedfirmware.org
Subject: [TF-A] Adoption of Conventional Commits

External email: Use caution opening links or attachments

Hi all,

Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future.

This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience.

With that in mind, I propose the following:

• We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands
• We suggest - in the prerequisites documentation - the installation of two helper tools:

• Commitizen
• Commitlint

Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation).

You’ll find the patches here, and specifically the changes to the prerequisites documentation here. Feel free to review these changes if you have comments specifically on their implementation.

Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly.

Chris