After seeing a few Conventional Commits messages, I personally do not find them very useful.
Granted, the intention of clearly describing the change is good. However, the "feat(abc)" prefixes do not add much value IMHO, but require extra cognitive effort to parse. I still have to read the whole message or even the diff to be sure I understand what the change is about. Just my 2 cents. Cheers, Dmitri. On Mon, May 19, 2025 at 2:27 PM Alex Dutra <alex.du...@dremio.com.invalid> wrote: > Hi all, > > I'm obviously +1 on Robert's proposals. Should we modify our > CONTRIBUTING.md guidelines? > > Also, in the spirit of standardizing how commit messages should be > formatted, I suggest that we take a look at the Conventional Commits > spec [1]. > > This small spec is becoming more and more popular (I already see some > contributors applying it to Polaris PRs – see this one [2] for > example). The big advantage of having a standardized commit format is > that tools & plugins would be able to extract more meaningful > information from commits, in order, for example, to generate a curated > changelog split in sections, while avoiding common noise, such as > commits marked as "chore" or generated by bots. > > [1]: https://www.conventionalcommits.org/en/v1.0.0/ > [2]: https://github.com/apache/polaris/pull/1614 > > Thanks, > > Alex > > On Mon, May 19, 2025 at 6:09 PM William Hyun <will...@apache.org> wrote: > > > > +1 on this suggestion, it would be good practice for everyone. > > > > Bests, > > William > > > > On Mon, May 19, 2025 at 7:56 AM Prashant Singh > > <prashant.si...@snowflake.com.invalid> wrote: > > > > > +1 to the suggestion ! > > > > > > On Mon, May 19, 2025 at 7:39 AM Dmitri Bourlatchkov <di...@apache.org> > > > wrote: > > > > > > > Great suggestions, Robert! Thanks for writing them down. > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Mon, May 19, 2025 at 8:34 AM Robert Stupp <sn...@snazy.de> wrote: > > > > > > > > > Hi all, > > > > > > > > > > Looking a bit ahead with respect to releases and (semi) automatic > > > > releases: > > > > > > > > > > We have a script that automatically collects the code changes from > the > > > > > Git log and adds it to the release-notes. While PRs usually have > some > > > > > meaningful information in the description, that information is > often > > > > > lost in the merged commits. > > > > > > > > > > The Polaris project uses the GitHub default to populate the commit > > > > > message for the "squash and merge" option from the messages of all > > > > > commits in the PR. > > > > > > > > > > The easiest way to get the "meaningful" information from the PR > > > > > description into the Github-proposed message is to have that in the > > > > > branch for the PR - if that branch has only one commit. In other > words: > > > > > when you open a PR and have only one commit in the PR branch, that > > > > > commit's subject and message are used to populate the PR summary + > > > > > description. > > > > > > > > > > For the (generated) release-notes and the Git commit log in general > > > > > having the actual description of the changes is very valuable. > > > > > > > > > > Please take the time _before_ hitting "squash and merge" and check > & > > > > > update the subject and message fields. It's not much work but > brings a > > > > > lot of value later. Remove the irrelevant messages from the > > > > > "intermediate commits" (like "test fix" or "make it compile") and > help > > > > > people who later look at the Git log by having the relevant parts > of > > > the > > > > > PR summary+description included in the merged commit. > > > > > > > > > > For "release managers" it's probably quite a lot of unnecessary > work to > > > > > do this in hindsight and inspect every PR. > > > > > > > > > > Robert > > > > > > > > > > -- > > > > > Robert Stupp > > > > > @snazy > > > > > > > > > > > > > > > > > >
