Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta: Include consequences of bugfixes in PR/commit messages #13612

Open
gdevenyi opened this issue Jun 30, 2022 · 3 comments
Open

Meta: Include consequences of bugfixes in PR/commit messages #13612

gdevenyi opened this issue Jun 30, 2022 · 3 comments
Labels
Type: Feature Feature request or new feature

Comments

@gdevenyi
Copy link
Contributor

While my ability to develop code for ZFS is limited, I try to keep abreast of the happenings by reading the PRs/commits, and I've found this common difficulty.

Take for example: 9e0b42e (#13015)

This PR/commit message tells me on a technical level what the bug was, and how it was fixed, but it doesnt tell me

  • how this bug could be triggered
  • what the consequences of the bug are (crash? Data loss? inability to import pool?)

I'd like to request a new checkbox be added for the PR/commit process that provide's a user-level interpretation of what changes are wherever possible. This results in a sort of self-documenting history of reasons/motivations which can be lost otherwise, and enables the eventual autogenerated changelog to be more useful when a release is generated.

Thanks for your consideration.

@gdevenyi
Copy link
Contributor Author

gdevenyi commented Aug 4, 2022

A follow-up of an additional request, document as well

  • when a bug is fixed indicate which releases the bug affected

@gdevenyi
Copy link
Contributor Author

gdevenyi commented Oct 4, 2022

https://github.com/openzfs/zfs/releases/tag/zfs-2.1.6 does not track user-visible bugfixes in the way requested.

@tonyhutter
Copy link
Contributor

'I'd like to request a new checkbox be added for the PR/commit process that provide's a user-level interpretation of what changes are wherever possible.

Yes, reviewers should be reviewing the commit message to make sure they're clear. Often all that's needed is the addition of a simple "here's what it does" line if there existing message is technical (example #13797 (comment)).

when a bug is fixed indicate which releases the bug affected

You should be able to look this up from the release notes. Each commit in the release notes has a link back to the issue it fixes (assuming it had a #Closes line in the commit message).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

No branches or pull requests

2 participants