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.org on behalf of Chris Kay via TF-A tf-a@lists.trustedfirmware.org Reply to: Chris Kay Chris.Kay@arm.com Date: Thursday, 11 February 2021 at 13:59 To: "tf-a@lists.trustedfirmware.org" 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
Just a reminder to everybody that we’re now most of the way through March, and therefore most of the way through the investigation period.
If anybody has any proposals they’d like to make, please do share them as soon as possible so that we have time to brainstorm and come to a conclusion. Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release.
Chris
From: Chris Kay Chris.Kay@arm.com Date: Thursday, 25 February 2021 at 17:30 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits 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.org on behalf of Chris Kay via TF-A tf-a@lists.trustedfirmware.org Reply to: Chris Kay Chris.Kay@arm.com Date: Thursday, 11 February 2021 at 13:59 To: "tf-a@lists.trustedfirmware.org" 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
Hi all,
As we received no follow-up to the previous email, we are now preparing to integrate Conventional Commits into Trusted Firmware-A.
The patches to support this in Trusted Firmware-A can be found here:
* https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/12 * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8225/11 * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8226/11 * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8227/12
Additionally, if you’d like to familiarise yourself with the new OpenCI, the patch integrating support for commit linting can be found here:
* https://review.trustedfirmware.org/c/ci/tf-a-job-configs/+/9694
As discussed, this will be rolled out initially only for @arm.com addresses and will be expanded for everybody upon the 2.5 release, so please familiarise yourself with the Conventional Commits specificationhttps://www.conventionalcommits.org/en/v1.0.0/#summary (it’s very short!), or give the tools a shot locally (see the prerequisites documentationhttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/12/docs/getting_started/prerequisites.rst) if you prefer a more interactive experience.
Happy committing!
Chris
From: Chris Kay Chris.Kay@arm.com Date: Thursday, 18 March 2021 at 12:07 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits Just a reminder to everybody that we’re now most of the way through March, and therefore most of the way through the investigation period.
If anybody has any proposals they’d like to make, please do share them as soon as possible so that we have time to brainstorm and come to a conclusion. Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release.
Chris
From: Chris Kay Chris.Kay@arm.com Date: Thursday, 25 February 2021 at 17:30 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits 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.org on behalf of Chris Kay via TF-A tf-a@lists.trustedfirmware.org Reply to: Chris Kay Chris.Kay@arm.com Date: Thursday, 11 February 2021 at 13:59 To: "tf-a@lists.trustedfirmware.org" 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
tf-a@lists.trustedfirmware.org
-
Chris Kay