Hi George,
Few clarifications.
it would need significant investments on tooling
[VW] I am not sure why you say that. The only expectation form tooling perspective is to run the ‘git log’ command before the release.
There is no tool which could help developers crafting the commit message in the right format
[VW] I don’t think we need a tool to generate commit messages with the right tags. I expect developers to add the tag manually as the footer. Maintainers will have to check that tags exist as part of the reviews.
Possibly the easiest would be to modify the javascript machinery available for Conventional Commits
[VW] I don’t think we need any tools from the “Conventional Commits” toolbox for this to work.
My proposal was from the requirements I heard from Chris in the meeting. If there are any implicit or obvious requirements that I missed, I propose we freeze them first. A solution can only work if the requirements are frozen.
-Varun
From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: Sunday, February 28, 2021 11:14 PM To: Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; tf-a@lists.trustedfirmware.org Cc: nd nd@arm.com; nd nd@arm.com Subject: RE: [TF-A] Adoption of Conventional Commits
External email: Use caution opening links or attachments
Hi Varun,
I really like your proposal, but it would need significant investments on tooling. There is no tool which could help developers crafting the commit message in the right format, there is no tool, which can validate the format (and be used i.e. as a git-hook), and there is no tool, which can generate the change history document from git history. Can you please extend the proposal and turn it to be an end-to-end solution? Can you contribute tooling for commit message editing and validation, and for change log document generation? Possibly the easiest would be to modify the javascript machinery available for Conventional Commits. Can you contribute the needed changes?
/George
From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: 26 February 2021 00:39 To: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits
Hi,
I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec.
The approach would be
1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections.
*git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix">
‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message.
Advantages
1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal
Thoughts?
-Varun
From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits
External email: Use caution opening links or attachments
Thanks to all those who attended the Tech Forum today!
It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved.
If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this.
Chris
From: TF-A <tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org> on behalf of Chris Kay via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Reply to: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org" <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Adoption of Conventional Commits
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 Commitshttps://www.conventionalcommits.org/en/v1.0.0/ 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:
* Commitizenhttps://github.com/commitizen/cz-cli * Commitlinthttps://github.com/conventional-changelog/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 herehttps://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%22+(status:open%20OR%20status:merged), and specifically the changes to the prerequisites documentation herehttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/getting_started/prerequisites.rst. 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