linux-kernel - Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state in rtl8366rb

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240311101422.2f48360e@kernel.org>
Date: Mon, 11 Mar 2024 10:14:22 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Simon Horman <horms@...nel.org>, Luiz Angelo Daros de Luca
 <luizluca@...il.com>, Linus Walleij <linus.walleij@...aro.org>, Alvin
 Šipraga <alsi@...g-olufsen.dk>, Andrew Lunn
 <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean
 <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state
 in rtl8366rb

On Mon, 11 Mar 2024 17:19:59 +0100 Krzysztof Kozlowski wrote:
> No, it does not reset the version number, because RFC->PATCH does not
> mean that suddenly there were no reviews or changes. We all count in
> brains from 1, so whatever we see - RFC, RFT, RFkisses or hugs - is the
> first version we see. Then next one, whatever it is called PATCH,
> RF-non-comments, RFmorekisses, is v2.

I'm describing what I see as the prevalent interpretation on netdev,
more than expressing an opinion. It's not based on any guidance from
us, people just seem to think that they should reset when they post
a PATCH.

Whether we want to enforce a different scheme is up for a discussion,
I don't really care. But I do see how not resetting is easier for
tools, and that I think is a _bad_ reason to add rules.

> There are RFCs which go to "v4", with significant discussion and review,
> thus natural next version is "5", not "1".
> 
> It's extremely confusing for me to be involved in some sort four
> revisions of RFC and the suddenly see v1. What happened with my
> comments? Why its state should be the same as new submission state?

Well, as I said, changelog with links in the cover letter...

> Plus, people do not understand or do not have the same meaning of RFC.
> Some people send RFC with meaning "do not apply, just some
> work-in-progress" but some send as regular patch with intention to
> apply. I really, really saw exactly these two approaches.

Yeah, that I do agree with 100%. People get confused by what RFC means.
I think it's partially maintainers' fault. Without naming names, there
are some people who used to apply RFC postings, if they liked the code
:|