RFC: PR phrasing: Fixes vs Closes

[edsantiago]

In #23672, contributor docs were updated to add:

If the patch fixes a logged bug entry, [...] "Fixes: #00000"

The wording here makes repeated use of the word "bug". The commit message implies that this change was made with the express goal of enforcing the word "Fixes" in LTS branches. There is no mention of any sort of issue other than bugs.

The word "Fixes" strongly implies that its corresponding issue is a defect or bug. This is misleading in the case of features or enhancements; hence github allows using "Closes" or "Resolves".

Do we have a policy on using "Closes" or "Resolves" for non-bugs? Should we?

[Luap99]

IMO trying to differentiate between bugs and features does not add much value (in terms of linked issues). The link points to something add that thing is either labelled bug/feature or something else. So I see more value in having one consistent word (Fixes) for linking any issue even when it is a feature.

When writing automation to check such lines it is much simpler to match a single word than all the different things, i.e.

podman/contrib/cirrus/pr-removes-fixed-skips

Line 154 in b65f3b1

while ($msg =~ /\b(Fix|Clos|Resolv)[esd]*[:\s]+\#(\d+)/gis) {

But overall I really do not care strongly about what word to use but I think there is value in a consistent way and not letting everyone do it differently. What I really care about is that people consistently link the correct issues and that they are auto closed on merge.

[edsantiago]

My bad; I had meant to address that.

There is no need for automation to check for anything other than Fixes. The automation is intended for RHEL branches, in which nothing goes in except bug fixes.

[Luap99]

Customers can get features backported too if they are important enough. And in the case I linked the automation runs on main PRs to check for FIXME skips which is a great thing but needs handling for 3 keywords vs 1. So any automation that want to check anything like it has to ensure it checks all of them, I guess given we already use all of them they might need to deal with it anyway if they want to analyse the git history for example so maybe limiting one is not practically useful either for such scripts.