Would it be possible to use the /branch/name for the "conventional"
part -- i.e. fix/my-branch - feat/something? I guess not as once the PR
is merged the name of the branch is not easily accessible anymore,
right?
-ash
On Mon, Jun 14 2021 at 09:08:45 +0100, Ash Berlin-Taylor
<[email protected]> wrote:
I also don't like conventional commits - and ultimately I don't think
for commit logs are the right tool for building a changelog - they
are too granular and also too noisy.
Primary reasons for not liking them: it uses up a lot of space in the
already short commit subject "limit", it's subjective, it can't be
changed after the commit is merged.
If the goal is to make building change logs easier and more useful
I'd rather we used a tool designed for that -
<https://docs.openstack.org/reno/latest/>
This also natively handles our cheery pick process, and also gives us
the ability to edit changelogs if we notice a typo for instance.
-ash
On 14 June 2021 03:39:50 BST, Tzu-ping Chung
<[email protected]> wrote:
There is also a tool called commitizen that helps teams standardise
commit messages. There is a Python implementation:
<https://commitizen-tools.github.io/commitizen/>
I’m not a huge fan of semantic commit messages and never
personally used any tooling for it, but one of commitizen’s
co-maintainers is a friend of mine, and I’ve been listening to his
pitches for a while now, so I guess I don’t really mind and can
probably adapt to it if needed. As long as we *don’t* use emoji
tags
<https://gist.github.com/alpteo/e93d754e5e09907c6362c4230fb66f87>.
Those are terrible.
TP
"Janardhan" <[email protected] <mailto:[email protected]>>
(13/06/21 19:31:52):
Hi,
I am new to Apache Airflow.
May be the following example guide would also be helpful.
There is a commit style guide[1] for Apache SystemDS based it's
commit history over the last 10 years.
It lists the tags used, and provides the type of commits including
a list of attributes to be included in its description and example
commits.
Thank you,
Janardhan
[1]
<https://github.com/apache/systemds/blob/master/CONTRIBUTING.md#commit-style>
On Sunday, June 13, 2021, Tomasz Urbaszek <[email protected]
<mailto:[email protected]>> wrote:
Related discussion from last year ("Use semantic pull request"):
<https://lists.apache.org/thread.html/r076232c60600238f37277497f66fb7eb9507869b92403c5ef96dcb3e%40%3Cdev.airflow.apache.org%3E>
On Sun, 13 Jun 2021 at 12:56, Jarek Potiuk <[email protected]
<mailto:[email protected]>> wrote:
>
> Hey everyone,
>
> I would like to hear people's opinions on using
semantic/conventional
> commits. I see people occasionally using it, but unless we make
it a
> "standard" and mandatory (and fail CI if commits are not
following
> it), IMHO there is virtually no benefit for the whole community.
>
> I am now preparing the June provider's release (a little
delayed due
> to my unavailability - sorry) and with 60+ providers it's
somewhat
> manageable without it. I semi-automatically prepare and
maintain all
> the changelogs now for all providers (I implemented a very
simple
> heuristics to help with it and classify the commits based on the
> commit message) but it requires quite some effort to
re-classify the
> changes. Not much, it's manageable, but having
semantic/conventional
> commits would make my (and other release managers) life a bit
easier.
>
> For those who are not familiar with - here is the "gist" of it
with links:
>
<https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716>
>
> In short - here are examples of semantic/conventional commit
messages:
>
> feat: add hat wobble
> fix: fix the hole eaten by moles
> doc: describe the hat etiquette
> style: make hat follow latest hat conventions
> refactor: replace hat underlying construction to be more sturdy
> test: test the hat when it's raining
> chore: cleanup the hat, it became dusty a bit
>
> Questions:
>
> * What's your experience with using the semantic/conventional
commits?
> * Do you like/dislike the semantic/conventional commits?
> * Should we make them mandatory?
> * Maybe there are other ways we can achieve the same results?
>
> J.
>
>
> --
> +48 660 796 129
