Hmm interesting. The real advantage of the "news" or blurb files is what Ash mentioned is that you can change them after they've been committed.
I am not totally against it, that does sound interesting, and forces you to think a bit when you realise that the file is missing. I wonder what others think about it? On Mon, Jun 14, 2021 at 4:51 PM Tzu-ping Chung <[email protected]> wrote: > > "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 > -- +48 660 796 129
