[Starlingx-discuss] Please Review: Requirements for commit messages
Ghada.Khalil at windriver.com
Fri Sep 13 15:35:14 UTC 2019
I should also clarify that I am not suggesting a unique story for each commit. On the contrary, I personally like bigger scope stories with multiple tasks for the different commits. Even the tasks don't need to be unique per commit; multiple commits can link back to the same task.
For example, fixing compile warnings as a prep for multi-OS support. This is one story with multiple tasks/commits.
Anyway my 2 cents :) I'll give a chance to others to chime in.
From: Khalil, Ghada
Sent: Friday, September 13, 2019 11:11 AM
To: 'Saul Wold'; starlingx-discuss at lists.starlingx.io
Subject: RE: [Starlingx-discuss] Please Review: Requirements for commit messages
This was discussed previously and, as a community, we agreed that this is the guideline for starlingx submissions
Link your review to a StoryBoard Story or Launchpad Bug For traceability, always link your code change to a story or bug. The story/bug will give reviewers context for the code changes. This will also be used to help determine the relative priority of the code changes.
I personally don't see a big barrier to creating a generic storyboard for spelling or cleanup tasks. Happy to hear from others their opinion.
I'm not terribly concerned about a few small updates without a link, but we should all aim to favor traceability (and document the purpose for the changes we're making).
From: Saul Wold [mailto:sgw at linux.intel.com]
Sent: Thursday, September 12, 2019 5:53 PM
To: starlingx-discuss at lists.starlingx.io
Subject: [Starlingx-discuss] Please Review: Requirements for commit messages
I would like to clarify the requirement or lack there of for having Bugs or Stories in commit messages. There are patches that are clearly addressing bug fixes and those should have a Closes-Bug; there are commits that are clearly implementing features that should have the Story/Task tags.
There are also commits that fall in between, they are not directly related to a given feature or have a bug filed, they are typically smaller and are fairly self-documenting or have good commit messages explaining why the change is needed, not just what the change does.
Ultimately Closes-Bugs and Story tags will help reviewers and other get the infomration needed to create release notes, but we don't need to document every change like spelling, indentation, fixing compiler warnings in Release notes.
I believe that we should have some flexibility in allowing for changes without related launchpad or story connections. This can help reduce the barrier to entry for small changes that community members may want to propose.
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
More information about the Starlingx-discuss