"Jarek Potiuk" <[email protected]> (14/06/21 20:06:14):
I never used tools like Reno (so I might be wrong) but I think they
add extra effort and requirements (and confusion) for contributors to
also modify the changelog pretty much always.
IMHO for new contributors it will lead to "default" one more extra
iteration of review ("and please update the changelog") with any code
change which otherwise would not be needed. This will be especially
confusing because we have now 70+ changelogs and sometimes the change
applies to several providers (for transfer operators) so several
changelogs should be updated.
Is there anyone who used such tools in a sizable project with multiple
contributors (including a lot of first-time comitters) and can share
their experiences?
Projects I involved with generally use bots to automatically go through
this “hey you need to add a changelog” phase. It is indeed a hassle for
contributors, but Airflow already has a ton of checks a new contributor
needs to be aware of, the overhead of adding yet another one is less of
an issue (compared of from zero to one).
CPython uses a home-brewed tool called Blurb
<https://pypi.org/project/blurb/> for changelog management, and a bot
called Bedevere handles the news entries review (and a bit more). It
automatically comments under a PR after checking, and edits the top
message to supply relevant information when checks pass.
Pip uses Towncrier <https://github.com/twisted/towncrier> (developed by
the same folks maintaining Twisted) and uses a check to mark the PR with
a red cross if the news entry is missing. There is a pre-commit check as
well (but as you know, very few contributors would actually set
pre-commit up, so that’s less effective).
The most lightweight setup I’m in touch with is pipx, where we just add
a checkbox to the PR template and tells the contributor to check it
after following the news entry instruction. Up until now every new
contributor I can remember automatically does the right thing without
issues.
All those tools work more or less the same (a file is added for each
feature, and those are collected into a section in the actual release
note file when a release is made), so I’d imagine it shouldn’t be too
difficult for Airflow to implement some kind of automation to keep the
friction low for both contributors and reviewers.
TP
J.
On Mon, Jun 14, 2021 at 1:30 PM Ash Berlin-Taylor <[email protected]> wrote:
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. Those are terrible.
TP
"Janardhan" <[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]> 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]> 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
--
+48 660 796 129
