Re: [PATCH 0/2] fuzz: build fuzzers by default on Linux

2 messages, 2 authors, 2024-04-09 · open the first message on its own page

Re: [PATCH 0/2] fuzz: build fuzzers by default on Linux

From: Junio C Hamano <hidden>
Date: 2024-03-26 21:51:11

Josh Steadmon [off-list ref] writes:
Increase our protection against fuzzer bit-rot by making sure we can
link the fuzz test executables on Linux. Patch 1 is a small CI config
improvement to fix compiler feature detection. Patch 2 is the Makefile /
config.mak.uname change to add the executables to `make all` on Linux.
This has seen a handful of review comments but they haven't been
responded nor resulted in a new round.  Can we wrap this up anytime
soon?

We would expect a review comment to be at least responded to either
rebut or admit the issues raised.  It may be that a reviewer's point
were missing the mark and the patches themselves were perfectly
fine.

But all other cases, even when the reviewer's comment were missing
the mark, such a confusion may have been the result of the patch
text or the proposed log message being unclear.  Of course, the
review comments may have been pointing out an actionable issue.
They would hopefully lead to an improved version of the patches
posted sometime later, so that we can conclude a topic and move
ahead.

Thanks.

Re: [PATCH 0/2] fuzz: build fuzzers by default on Linux

From: Josh Steadmon <hidden>
Date: 2024-04-09 21:34:44

On 2024.03.26 14:51, Junio C Hamano wrote:
Josh Steadmon [off-list ref] writes:
quoted
Increase our protection against fuzzer bit-rot by making sure we can
link the fuzz test executables on Linux. Patch 1 is a small CI config
improvement to fix compiler feature detection. Patch 2 is the Makefile /
config.mak.uname change to add the executables to `make all` on Linux.
This has seen a handful of review comments but they haven't been
responded nor resulted in a new round.  Can we wrap this up anytime
soon?

We would expect a review comment to be at least responded to either
rebut or admit the issues raised.  It may be that a reviewer's point
were missing the mark and the patches themselves were perfectly
fine.

But all other cases, even when the reviewer's comment were missing
the mark, such a confusion may have been the result of the patch
text or the proposed log message being unclear.  Of course, the
review comments may have been pointing out an actionable issue.
They would hopefully lead to an improved version of the patches
posted sometime later, so that we can conclude a topic and move
ahead.

Thanks.
Sorry for letting this sit for so long. I'll be addressing comments and
sending a V2 soon.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help