netdev - Re: [PATCH net-next] docs: netdev: clarify the need to sending reverts as patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 29 Mar 2023 12:02:12 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        pabeni@...hat.com, corbet@....net, linux-doc@...r.kernel.org,
        Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [PATCH net-next] docs: netdev: clarify the need to sending
 reverts as patches

On Wed, 29 Mar 2023 11:04:01 +0200 Thorsten Leemhuis wrote:
> FWIW, I see how this is well meant, but I'm not really happy with the
> last sentence, as one of the problems I notice when handling regression
> is: it sometimes takes weeks to get regressions fixed that could have
> been solved quickly by reverting the culprit (and reapplying an improved
> version of the change or the change together and a fix later). That's
> why Documentation/process/handling-regressions.rst strongly suggest to
> revert changes that cause regressions if the problem can't be fixed
> quickly -- especially if the change made it into a proper release. The
> two texts thus now not slightly contradict each other.
> 
> I noticed that this change was already applied, but how would you feel
> about changing the second sentence into something like this maybe?

Please escalate the cases which can be fixed by easy reverts because 
I can't think of any in networking :(

The entire doc is based on our painful experience telling people the
same thing over and over again, we don't want to include things which
don't actually happen on netdev. Longer the doc is the less likely
people will actually read it :(