Pinging specific iface does not work: Fix broken parentheses in setsockopt call (IDFGH-5676)

[ivmarkov]

The call to setsockopt has the parentheses in a wrong way, which causes the whole functionality of pinging a specific netif instance to fail.

[CLAassistant]

All committers have signed the CLA.

[Alvin1Zhang]

Thanks for your contribution.

[AxelLin]

Just remind that v4.3 and v4.2 also need the fix.

[AxelLin]

Hi @igrr @Alvin1Zhang

This one is a classic case of one-line-fix which fixes a real bug.
I'm wondering if espressif has some standard process to speed up merging such fix.

I asked this because it may take very long time to apply to impacted branches.

Below is another example of such one-line-fix which fixes a real bug.
#7047 (And people are waiting, e.g. #7047 (comment) )

19 May 2021 Issue reported
7 Jun 2021 Commit to master
30 Jun 2021 Commit to release/v4.3
And sync to github time is slightly longer than the commited time.

PS. I'm not asking to take special care of this PR. (@suda-morris did very quick response on this PR)
I'm asking if you have some standard process to speed up merging such fix.

[igrr]

@AxelLin Thank you for the suggestion. There is no existing special process for one-liner fixes compared to all other PRs. The basic process is: 1) the PR is assigned to a developer, 2) if the PR doesn't need additional work, the developer will create an internal merge request, adding release notes and any required tests, 3) code owners review the merge request, 4) once the merge request is approved it can be merged, 5) backport merge requests are created and handled in a similar way. Indeed PR handling gets stuck at different points, for example this PR is stuck at step 2, since the developer who is assigned happens to be on leave now. We are looking at options to automate more steps in this process to make the handling of PRs more efficient.

Regarding this specific bug, I don't necessarily agree with you that there is a need to speed up merging into release branches, unless the PR author specifically requests the bug to be fixed on a particular release. For bugs that result in random failures or unreliable behavior, we do need to backport them quickly, since users might encounter this issue without even changing much in their applications that are already deployed. On the other hand, for bugs that result in a certain use case being completely broken, we could argue that if noone has reported such issue for a release branch, the feature (or use case) is simply not used. Of course, we do need to fix the issue in release branches eventually. But due to lower impact, I would classify the urgency of backporting as "normal" rather than "high".

[AxelLin]

well, this is indeed not a regression because it actually never work.
However the API is there and if you call ping with specific interface
it will run into Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

[Alvin1Zhang]

Changes have been merged with ee531c7, thanks for your contribution again.

[AxelLin]

Would you apply this fix for v4.3 branch? (Unfortunately, v4.3.1 does not include this trivial fix).

[BaaBaaGoat]

just got fucked by that .V4.3 latest stable.