<div dir="ltr"><div dir="ltr"><div dir="ltr">Typically, when we do a z-release (or patch release), we cherrypick the individual changes based on the redmine issues set to be released (based on the Plaform Release field). In your example, if there was a new z-release of crane, issues 3 and 4 would be ignored since there is no issue they are associated with. Optimally, I would have probably created issues for commits 3 and 4 and have attached them each to those.<div><br></div><div>For features, (which get released with feature or x.y releases), attaching commits to issues is used for bookkeeping since these releases are branched off master (or with pulp 2, 2-master). In your example, you could have commit 3 have “ref #3857” and commit 4 have "closes #3857”. This way, the third commit wouldn’t affect the state of the issue but the fourth commit would close out the issue and both commits would be associated with #3857.</div><div><br></div><div><div><div><div><div dir="ltr" class="gmail-m_-2021791976929806738m_3994104879839848019gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 11, 2018 at 4:33 PM Simon Baatz <<a href="mailto:gmbnomis@gmail.com" target="_blank">gmbnomis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<br>
On Tue, Sep 11, 2018 at 10:15:22AM -0400, David Davis wrote:<br>
>    I want to announce that commit messages will be validated for PRs<br>
>    against pulp’s master branch per [0]. This validation will check two<br>
>    things.<br>
>    First, the validation script checks that there’s an attached issue in<br>
>    the commit message. This is to prevent commits not being properly<br>
>    associated with the issue they've fixed. If you absolutely must commit<br>
>    code without an issue, add “#noissue” to the commit message.<br>
<br>
I must admit that I am still confused which changes need an issue and<br>
what the link is good for during the build process.  Perhaps a more<br>
complex example could help: We had a "mixed bag" PR for Crane a<br>
couple of weeks ago [0] which consisted of the following commits<br>
(after improving it and splitting it up into 4 commits).<br>
<br>
4. Implement option to serve local content:<br>
<br>
  The core implementation of the feature<br>
<br>
3. Add "repository" to stored repo data from redirect files<br>
<br>
  Preparation for the actual feature.<br>
<br>
2. Fix app_util.validate_and_transform_repo_name()<br>
<br>
  Fix for a function to improve handling of edge cases.<br>
<br>
1. Fix logger name for v2 views<br>
<br>
  One line "drive by fix" to fix logging in a module.<br>
<br>
<br>
Let's assume 1. and 2. are commits one would consider to pick for a<br>
stable patch release (AFAIK this is currently not happening for Crane, but<br>
let's pretend).  3. and 4. belong to the implementation of a new<br>
feature (with 4. being the "meat").  The fixes were not planned<br>
before, they just made sense to do during implementation/review.<br>
<br>
In this PR, only 4. had an annotation linking it to the story ("closes #3857"). <br>
What would be the proper way to handle this PR with respect to issues<br>
and annotations in your opinion?<br>
<br>
<br>
[0] <a href="https://github.com/pulp/crane/pull/93/commits" rel="noreferrer" target="_blank">https://github.com/pulp/crane/pull/93/commits</a><br>
</blockquote></div>