modin-project
DOCS: Automate release notes
Is your feature request related to a problem? Please describe. Our current development process requires contributors to explicitly add new changes to the Modin release notes. We should automate this process to that the release notes are automatically generated. We're seeing that a lot of folks are finding it as a point of friction.
@jbrockmendel do you know how pandas does this? This would reduce a lot of friction for merging in code. 😄
in pandas if a PR includes user-facing changes we ask the contributor to add a note in the appropriate whatsnew file. Not for e.g. refactoring or CLN PRs.
The discussed proposal here is to automate release notes by no longer requiring the diff to be added in the PR. Instead, we use a script that sifts through the a range of git commits and organizes them by the commit prefix (PERF, REFACTOR, TEST, FEAT, FIX). The upside to this method is that we won't have to deal with merge conflicts on the release notes. The downside is, we may lose some detailed categories in the release notes such as "Benchmarking enhancements", "OmniSci enhancements", "XGBoost enhancements". Thoughts?
cc: @modin-project/modin-contributors @modin-project/modin-core
@pyrito in addition, the length of the commit message is very limited, which sometimes does not allow me to add the necessary details.
@anmyachev I think that's ok. In my opinion, commit messages should be concise and necessary details should always be mentioned in the description of the PR.
@pyrito I think the main difficulty in compiling this list is to go through each commit (as it used to be) - it's tedious and error prone. However, if the list is generated automatically, it is enough to simply select the commits into groups, to which we now also add by hand.
I would not like to refuse grouping (by some special category), it makes it easier to find what you need.
@pyrito also, I like @jbrockmendel idea that we don't need to add changes to the list that are not interesting to users (like refactoring). Have you thought about excluding the corresponding prefix from your script?
@anmyachev fair enough. I think there will always be some level of manual effort to put together the release notes, especially if we want more detailed groupings. However, using the script will just easily filter through with the prefix of the commit.
I am ok with ignoring REFACTOR commits from the release notes.
Just building the initial release notes by commits will be enough, the "release person" might have to go through each PR to subdivide them better, but that is a one-time effort, so should be fine. IMO, this is a great trade-off compared to what we now require all contributors to do.
I also think dropping REFACTOR- would be fine, or we can just list them in one comma-separated line at the very bottom, so users who're browsing via github would still see nice pop-ups, but they won't bother 99% of our users who don't care about codebase, but only about user-facing things.
P.S. On somewhat unrelated note, is there still a reason to require for each PR to have a corresponding issue?
P.S. On somewhat unrelated note, is there still a reason to require for each PR to have a corresponding issue?
@vnlitvinov let's discuss on #4982.
