+1

And I think Alex is right: it could be helpful to update contributing file
in the repo and on the website.

Regards
JB

Le lun. 19 mai 2025 à 20:26, Alex Dutra <alex.du...@dremio.com.invalid> a
écrit :

> 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
> > > > >
> > > > >
> > > >
> > >
>

Reply via email to