Re: Fix in branch 2025Q3 without a need to fix in main

Am 19.07.25 um 14:57 schrieb Rainer Hurling:
> Am 19.07.25 um 14:39 schrieb Moin Rahman:
>>
>>
>>> On Jul 19, 2025, at 14:24, Rainer Hurling <rhurlin@gwdg.de> wrote:
>>>
>>> Dear committers,
>>> I have a question about a specific case that I haven't encountered 
>>> before:
>>>
>>> My port math/saga is at version 9.9.0 in the main branch and at 
>>> version 9.8.2 in the 2025Q3 branch. In version 9.8.2, a patch was 
>>> forgotten upstream during the release, which means that 9.8.2 now 
>>> fails to build in the package builders. (Interestingly, I can build 
>>> the version in Poudriere.) I would now like to commit the appropriate 
>>> patch only for version 9.8.2 in the 2025Q3 branch, as main in version 
>>> 9.9.0 already contains this patch.
>>>
>>> When I try to push the commit, I get the following message:
>>>
>>> ================================================================
>>> remote: rhurlin, you are pushing a commit to 2025Q3 which does
>>> remote: not seem to be a cherry-pick.
>>> remote:
>>> remote: If you did a cherry-pick, you probably forgot to add `-x`,
>>> remote: make sure you do run `git cherry-pick -x <hash>`.
>>> remote:
>>> remote: If you did a direct commit, make sure it was approved first, 
>>> and then run:
>>> remote:         git push --push-option=direct-quarterly-commit
>>> remote: ================================================================
>>>
>>> Do I actually need approval in the case described, and if so, from whom?
>>>
>>> Or can I simply push directly with the argument ‘--push- 
>>> option=direct-quarterly-commit’ instead?
>>>
>>> Thanks for your help.
>>>
>>
>> No. You do not need approval. But your direct commit should be
>> descriptive enough to justify the direct commit.
>>
>> Kind regards,
>> Moin
> 
> Thanks Moin,
> For your fast and helpful response.
> 
> I pushed the fix in https://cgit.freebsd.org/ports/commit/? 
> id=537022a43c518a1781879ace246c5114a38d4286.

And the bug is elusive because whether it breaks the build or not is 
implementation-defined, depends on the exact compiler chosen and how its 
stddef.h or thereabouts handle NULL.

Upstream should've used nullptr in C++ code, but that aside,

- anything that has #define NULL nullptr bombs out with an error

- anything that has #define NULL __null (GNU's extension NULL constant) 
will survive with a warning.

That makes for interesting artifacts:

14.3's base clang 19.1.7 bombs out because it has #define NULL nullptr, 
as does LLVM15 from ports, but LLVM 19 from ports has #define NULL 
__null and just warns.