x11/libxshmfence: clean up patches

[jbeich]

Test Plan

• poudriere bulk -t is green on 10.3 i386/amd64, 11.0 i386/amd64, 12.0 amd64

[jbeich]

devel/arcanist wants user! for blocking(user). If only I could find where the syntax is documented.

[rezny]

This appears completely backwards. Why would you lump the patches together when the preferred way to is to use makepatch? This only makes maintenance harder.

[jbeich]

In D11594#240316, @rezny wrote:

This appears completely backwards. Why would you lump the patches together when the preferred way to is to use makepatch? This only makes maintenance harder.

When dealing with many patches on updates having one patch per-file encourages accumulating cruft as maintainer can forget which pieces are related and which are not. For one, it's easy to overlook why files/patch-src__xshmfenceint.h is required here. Porter's Handbook explicitly allows multifile patches:

A patch may modify multiple files if the changes are related and the
patch is named appropriately. For example, patch-add-missing-stdlib.h.

[rezny]

Commenting the patch files to explain their purpose is a better solution. Just because patches may be combined doesn't mean it's a good idea nor the preferred way.

[jbeich]

Why do you focus on the style rather than correctness? Don't you care which version ends up upstream?

In D11594#240320, @rezny wrote:

Commenting the patch files to explain their purpose is a better solution.

What happens when there's more than one multi-file patch touching the same file? Have you tried to apply split patches mixed with unrelated changes from other projects such as OpenBSD Ports or PkgSrc? Do you consider cherry-picking FreeBSD patches by an upstream maintainer easier when they're split?

Just because patches may be combined doesn't mean it's a good idea nor the preferred way.

Most patches are trivial, unrelated and/or are already atomic. Adding a comment is usually enough as one can see the full context. As the complexity grows maintainer's bus factor lowers. Multi-file patches are one way to tackle it.

[rezny]

In D11594#240330, @jbeich wrote:

Why do you focus on the style rather than correctness? Don't you care which version ends up upstream?

As far as I see this differential is nothing but style so it is absurd to now object to my criticism thereof and mention correctness. Is there any content change hidden in here? There's certainly no indication of such and all I can readily see is everything got lumped into one file, which appears as entire removals and an addition with no line diffs. If you had a content change for correctness, that should be submitted as a digestible patch, not buried in needless consolidation.

What happens when there's more than one multi-file patch touching the same file? Have you tried to apply split patches mixed with unrelated changes from other projects such as OpenBSD Ports or PkgSrc? Do you consider cherry-picking FreeBSD patches by an upstream maintainer easier when they're split?

If the patch comes from an external source, i.e. upstream commit, then keeping it lumped together is reasonable for tracking and prompt removal upon updating to a release with the change present. As those do require extra care they should be temporary. What happens when more than one multi-file patch touches a file is a royal PITA and one of the reasons to avoid multi-file patches, so why do you mention that downside in defense of your proposed multi-file patch? If there's more than one and they aren't very temporary, then splitting is one solution to make them manageable. The alternative is naming tricks to ensure correct application, which could be used useful for tracking a set of upstream commits until the next release.

Going the other direction, sending patches to an upstream, depends largely on the upstream how those should be handled (one patch per change or all the BSD stuff in one heap, submit to mailing list or bug tracker, etc). I do not expect many upstream maintainers to look for patches in FreeBSD ports.

Just because patches may be combined doesn't mean it's a good idea nor the preferred way.

Most patches are trivial, unrelated and/or are already atomic. Adding a comment is usually enough as one can see the full context. As the complexity grows maintainer's bus factor lowers. Multi-file patches are one way to tackle it.

Given the problems with multi-file patches and the complexity they bring, claiming they are a way to tackle complexity is illogical. Aside from port's with team maintenance, the maintainer system encourages if not enforces a singular bus factor.

[manu]

Is that still accurate ?

[jbeich]

Obsolete after 8a88cd08d891.

x11/libxshmfence/files/patch-src_xshmfence__futex.h

10

Fixed upstream.