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]
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
:|

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ