Community: guidance on commit message style
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.
michelleN
All 13 comments
We can expand the section or maybe spin a sub-section here: https://github.com/kubernetes/community/tree/master/contributors/guide#code-review?
shubheksha
on 18 Apr 2018
I don't believe we have any convention for commit messages to k/k. We handle release notes through the Github PR body.
cblecker
on 18 Apr 2018
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
castrojo
on 19 Apr 2018
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
on 19 Apr 2018
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.
tpepper
on 19 Apr 2018
Bumping this again.
Looks like this should go as an email to the steering and the sig-contribex lists.
nikhita
on 20 Jun 2018
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.
nikhita
on 20 Jun 2018
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
fejta-bot
on 18 Sep 2018
/remove-lifecycle stale
shubheksha
on 18 Sep 2018
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
fejta-bot
on 17 Dec 2018
/lifecycle frozen
idealhack
on 19 Dec 2018
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.
@nikhita Noted, Working on it.
/assign
vishakhanihore
on 20 Dec 2019
/cc
hh
on 20 May 2020
Related issues
casusbelli
路
4Comments
alouane
路
4Comments
justaugustus
路
5Comments
rlenferink
路
4Comments
spiffxp
路
5Comments
Most helpful comment
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.