Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release.
IIRC, I already proposed another option that builds on the tagging mechanism from Conventional Commits. Did we document the objections somewhere? I remember, CC did get some "nays" on the wiki page. Were all those concerns resolved?
From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Chris Kay via TF-A Sent: Thursday, March 18, 2021 5:08 AM To: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits
External email: Use caution opening links or attachments
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.commailto:Chris.Kay@arm.com> Date: Thursday, 25 February 2021 at 17:30 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.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
Hi Varun,
We’re treating the mailing list and the tech forum recording as the primary documentation for this topic, but there don’t appear to be any remaining objections from the wiki comments that were not eventually touched upon here - both objections on the Wiki appear to be focused on concern about the subject length, which received a fair amount of debate.
We’ve seen no engagement past that; the discussion ceased entirely after the 4th, and we received no further responses to the broadcast sent on the 16th, so we began integrating Conventional Commits tooling into the tree and CI last week with the expectation that it will be integrated for the 2.5 release.
Chris
From: Varun Wadekar vwadekar@nvidia.com Date: Friday, 16 April 2021 at 01:55 To: Chris Kay Chris.Kay@arm.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] Adoption of Conventional Commits
Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release.
IIRC, I already proposed another option that builds on the tagging mechanism from Conventional Commits. Did we document the objections somewhere? I remember, CC did get some “nays” on the wiki page. Were all those concerns resolved?
From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Chris Kay via TF-A Sent: Thursday, March 18, 2021 5:08 AM To: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits
External email: Use caution opening links or attachments
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.commailto:Chris.Kay@arm.com> Date: Thursday, 25 February 2021 at 17:30 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.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
Hi,
It is discouraging to see that the concerns were only "touched upon" and no attempt was made to update the approach. It is even more discouraging to see that the scripting was rolled into the CI without the courtesy of announcing on the DL. I was hoping for a democratic environment - looks like the project has taken a turn for the worse. I understand that I can only state my objection and point out the missteps at this point.
Quick question - For 2.6, would the new commit message format be mandatory?
-Varun
From: Chris Kay Chris.Kay@arm.com Sent: Thursday, April 15, 2021 6:30 PM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits
External email: Use caution opening links or attachments
Hi Varun,
We're treating the mailing list and the tech forum recording as the primary documentation for this topic, but there don't appear to be any remaining objections from the wiki comments that were not eventually touched upon here - both objections on the Wiki appear to be focused on concern about the subject length, which received a fair amount of debate.
We've seen no engagement past that; the discussion ceased entirely after the 4th, and we received no further responses to the broadcast sent on the 16th, so we began integrating Conventional Commits tooling into the tree and CI last week with the expectation that it will be integrated for the 2.5 release.
Chris
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Date: Friday, 16 April 2021 at 01:55 To: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Adoption of Conventional Commits
Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release.
IIRC, I already proposed another option that builds on the tagging mechanism from Conventional Commits. Did we document the objections somewhere? I remember, CC did get some "nays" on the wiki page. Were all those concerns resolved?
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, March 18, 2021 5:08 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
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.commailto:Chris.Kay@arm.com> Date: Thursday, 25 February 2021 at 17:30 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.conventionalcommits.org%2Fen%2Fv1.0.0%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C6c85da92f0734f8e0ab808d9007723fc%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541333983217644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=DXDL1obasbxB5Xq4ES592xxI1BdQsawnJ5z4T8rBkl0%3D&reserved=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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fq%2Ftopic%3A%2522ck%25252Fconventional-commits%2522%2B(status%3Aopen%2520OR%2520status%3Amerged)&data=04%7C01%7Cvwadekar%40nvidia.com%7C6c85da92f0734f8e0ab808d9007723fc%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541333983227600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=mS37NKC%2BzoWHRilaeKMGD97CaGqO2Sqvt5lBdcqIvgk%3D&reserved=0, and specifically the changes to the prerequisites documentation herehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-A%2Ftrusted-firmware-a%2F%2B%2F8224%2F1%2Fdocs%2Fgetting_started%2Fprerequisites.rst&data=04%7C01%7Cvwadekar%40nvidia.com%7C6c85da92f0734f8e0ab808d9007723fc%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541333983227600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hbNzlyn5o2tzuMLWytPcYb8iHkNKI4oYLY%2FFDQKThbI%3D&reserved=0. 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
We did resolve objections that we could practically resolve, e.g. downgrading subject length errors to warnings. I've done what I can to demonstrate that egregious subject lengths are not something we are likely to encounter any more frequently than we do today, and we simply cannot afford to restructure our entire approach to allay the fear of something that we do not believe will manifest.
Ultimately, there is only so much we can do to facilitate a democratic environment. We have reached out to all maintainers via the mailing list, tech forum, wiki discussion and individual email, and where possible we have resolved concerns, encouraged debate, and opened the floor to practical alternatives. However, without participation from more than one or two maintainers we have little option but to act unilaterally under the pressures we have - the broadcast email warning of impending change was sent a month ago and was done with two weeks remaining for further discussion on alternatives, but we received no correspondence. If anything, considering the number of TF-A maintainers today, I would consider one outstanding objection to be rather a success - democratic governance does not mean everybody always comes away happy with the result.
The CI scripts have not yet been upstreamed - they are presently undergoing testing on the OpenCI, though there are some hiccups, as there always is with new infrastructure. We are expecting to make the commit scheme mandatory for everybody at the point of the 2.5 release, but we are hoping to enable it for @arm.com addresses at some point next week.
Chris ________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 16 April 2021 03:06 To: Chris Kay Chris.Kay@arm.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] Adoption of Conventional Commits
Hi,
It is discouraging to see that the concerns were only “touched upon” and no attempt was made to update the approach. It is even more discouraging to see that the scripting was rolled into the CI without the courtesy of announcing on the DL. I was hoping for a democratic environment – looks like the project has taken a turn for the worse. I understand that I can only state my objection and point out the missteps at this point.
Quick question - For 2.6, would the new commit message format be mandatory?
-Varun
From: Chris Kay Chris.Kay@arm.com Sent: Thursday, April 15, 2021 6:30 PM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits
External email: Use caution opening links or attachments
Hi Varun,
We’re treating the mailing list and the tech forum recording as the primary documentation for this topic, but there don’t appear to be any remaining objections from the wiki comments that were not eventually touched upon here - both objections on the Wiki appear to be focused on concern about the subject length, which received a fair amount of debate.
We’ve seen no engagement past that; the discussion ceased entirely after the 4th, and we received no further responses to the broadcast sent on the 16th, so we began integrating Conventional Commits tooling into the tree and CI last week with the expectation that it will be integrated for the 2.5 release.
Chris
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Date: Friday, 16 April 2021 at 01:55 To: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Adoption of Conventional Commits
Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release.
IIRC, I already proposed another option that builds on the tagging mechanism from Conventional Commits. Did we document the objections somewhere? I remember, CC did get some “nays” on the wiki page. Were all those concerns resolved?
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, March 18, 2021 5:08 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
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.commailto:Chris.Kay@arm.com> Date: Thursday, 25 February 2021 at 17:30 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.conventionalcommits.org%2Fen%2Fv1.0.0%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C6c85da92f0734f8e0ab808d9007723fc%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541333983217644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=DXDL1obasbxB5Xq4ES592xxI1BdQsawnJ5z4T8rBkl0%3D&reserved=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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fq%2Ftopic%3A%2522ck%25252Fconventional-commits%2522%2B(status%3Aopen%2520OR%2520status%3Amerged)&data=04%7C01%7Cvwadekar%40nvidia.com%7C6c85da92f0734f8e0ab808d9007723fc%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541333983227600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=mS37NKC%2BzoWHRilaeKMGD97CaGqO2Sqvt5lBdcqIvgk%3D&reserved=0, and specifically the changes to the prerequisites documentation herehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-A%2Ftrusted-firmware-a%2F%2B%2F8224%2F1%2Fdocs%2Fgetting_started%2Fprerequisites.rst&data=04%7C01%7Cvwadekar%40nvidia.com%7C6c85da92f0734f8e0ab808d9007723fc%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541333983227600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hbNzlyn5o2tzuMLWytPcYb8iHkNKI4oYLY%2FFDQKThbI%3D&reserved=0. 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 -
Varun Wadekar