[PATCH master,23.05] ramips: fix ZyXEL NR7101 bricking typo

Bjørn Mork bjorn at mork.no
Mon Oct 16 00:32:04 PDT 2023

Christian Marangi <ansuelsmth at gmail.com> writes:
> On Sun, Oct 15, 2023 at 09:59:57PM +0200, Paul D wrote:
>> On 2023-10-15 19:41, Bjørn Mork wrote:
>> > And it would be great if we could have some automated check
>> > to help us spot these kinds of unrelated and unexpected
>> > changes.  I don't think the regular review process will ever
>> > be able to catch this, as that is mostly focues on the newly
>> > added device.
>> While I second the urgency of this, I venture the question of how one might
>> otherwise catch these things, but for sharp eyes. There is an attention
>> deficit with respect to the volume of patches and PRs that come in.
> Well the only solution is being more aggressive with nitpicking and
> request very dry patch with less patch delta as possible.
> The PR was introducing a new device so it's understandable to not think
> that on moving code, the guy introduced a typo in rewiting the entry in
> the shell...
> It's both trusting the submitter and not expecting these kind of error
> :(

I believe it's understandable how such an error can happen with humans

The error is probably a simple matter of "spurious typing". I don't
think we can expect any reviewer, including the submitter, to spot this.
It's a single character in an legitimately modified part of a file.  The
resulting diff is pretty much as expected, without any extra blobs. And
the expected new-device change is trivial, so it's not where any
reviewer would (or should) spend their time.  Their focus is obviously
on the new device anyway.

It's not uncommon to see similar errors slip through and end up in
"main".  The only difference with this one was that it was so subtle
that it only broke new installs of a single, rare, device.

I have no solution to offer, unfortunately.  Which was why the question
was open without actual suggestions on how to improve this.  Hoping that
smarter people than me can come up with something.

But a solution has to be scripted/automated IMHO. Making it a reviewer
problem will not solve anything. It will only create more problems by
abusing reviewer resources.


More information about the openwrt-devel mailing list