guidance on commit message style

[michelleN]

Would be great to add some guidance on what your commit message should look like when contributing a PR to kubernetes/kubernetes if there is a format/convention. Some repos have a specific commit message style that helps with generating release notes. See this one as an example.

[shubheksha]

We can expand the section or maybe spin a sub-section here: https://github.com/kubernetes/community/tree/master/contributors/guide#code-review?

[cblecker]

I don't believe we have any convention for commit messages to k/k. We handle release notes through the Github PR body.

[castrojo]

I agree that this should part of the contributor guide.

@tpepper - you spent some time mentoring me with some great tips, maybe we can work on this together as a default recommendation?

/area contributor-guide

[tpepper]

I like the Deis example, although I'm not sure why there's a "footer", unless it was meant to be preceded by a line with '''---''' for '''git-send-email''' usage as described for example in the section '''The canonical patch format''' of the linux kernel patch submission guidelines.

Also this one from a past project I worked on goes into a bit of example detail.

I feel like the internet has sort of resolved onto Chris Beams' write up as the canonical answer to this problem. That's referenced in the code review section of the contrib guide. There we opted to be concise, arguably to a fault. I think more details would fall nicely into the pull request doc.

[tpepper]

Also it's worth noting that there hasn't been / is not a rigorous format convention today if you look though k/k and other k/* repos. I for one would very very very much welcome the start of a format convention like those linked above. But does that become something for steering? There's bound to be at least some push back to the idea and it only becomes convention if it's widely used, which at one end of the spectrum argues for test automation or at the other end buy in from sufficient number of approvers to accomplish equivalent less forcefully. Personally I like automation because it's clear and immediate feedback, especially when enabled on your own forks' branches.

[nikhita]

Bumping this again.

Looks like this should go as an email to the steering and the sig-contribex lists.

[nikhita]

Would be great to add some guidance on what your commit message should look like

maybe the contributor guide could just "suggest" the changes and not enforce a certain style? Enforcing a certain style doesn't provide any tangible benefit per se (with respect to release notes, etc) but is a nice-to-have.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[shubheksha]

/remove-lifecycle stale