Bug: contribution guidelines contradict git guidelines

[AlexanderLanin]

Current state

Contribution Request Guideline states For simple contributions, like fixing bugs or improvements, just creating a PR is sufficient.

Git Guidelines state that Issue-ref: <Keyword> #<IssueNr> is a mandatory part of commit messages.

Implementation mandates the Git Guidelines wording.

Issue

When creating a simple pull request, there is no issue which could be referenced. We already agreed to not have a default issue in such cases, since we wanted to follow common practices on GitHub.

Referencing the pull request itself is also impossible, since the commit is created before the pull request.

Alternatives

• Remove the need for Issue-Ref completely (my favorite, since this is common practice on GitHub)
• Add "fixup" or "chore" as an additional possibility to issue-ref (vote by @ltekieli, see git: Remove requirement for commit body to reference an issue #117)
• ...more?

[ltekieli]

I meant add a commit title prefix like "fixup:" or "(chore)", that will skip checking the issue-ref completely. Eg.:

[ignore-by-title]
# Match commit titles starting with "(chore)"
regex=^\(chore\)(.*)
ignore=body-match-regex

[AlexanderLanin]

Ah, that makes more sense :-)

But I have a little issue with the commit title anyway: #88 (comment)

[ltekieli]

But I have a little issue with the commit title anyway: #88 (comment)

Similar to the previous internal setup, we should have the squash option disabled, and rely on the users being able to correctly structure a PR with proper commits.

[AlexanderLanin]

While I agree, that makes reviews difficult as we loose the "show diff since last review" option.

[LittleHuba]

Referencing the pull request itself is also impossible, since the commit is created before the pull request.

Github adds that reference in its frontend automatically. Hence, there is no need to put it manually. If there is an issue that a PR fixes, then the PR shall link to that issue.

I strongly favor just removing Issue-ref completely. There is no benefit in forcing users to manually put a number there, where we can not check that the right number was put.
If somebody really wants to highlight the relationship, he still can, but making it mandatory is no benefit.

[pahmann]

I agree that Issue-Refs are nothing which is typically used in GitHub. On the other side, nobody can point me to a project argumenting ISO 26262 compliance.

Beside that we can see that ThreadX e.g. with https://github.com/eclipse-threadx/threadx/pull/159/files does not use any reference in their PRs, but have a manual version history in their files.
Another thing observed is SpaceROS which have a check that Issues are properly referred. They have this integrated to comply with the NASA development process. See e.g. space-ros/space-ros#186

What we have to consider is, that we will not enforce every OSS project we consume to use Issue-Refs: So what about unused code. Also, they may reject our patches to upstream, in case we include Issue-Refs. in there. We would need to maintain two versions of patch and cannot go upstream properly in case we do a fix.