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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Mon, 11 Mar 2024 11:52:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 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 14:40:44 -0400 Konstantin Ryabitsev wrote:
> On Mon, Mar 11, 2024 at 09:11:11AM -0700, Jakub Kicinski wrote:
> > > OK, then this is v2. RFC is state of patch, not some sort of version. Or
> > > just use b4 which handles this automatically...  
> > 
> > Eh, hum. He does according to the X-Mailer header. More importantly
> > I thought the RFC to PATCH transition resetting version numbering
> > is how we always operated. Maybe b4 should be fixed?  
> 
> There is no way to make it work reliably the way you propose,

Could you describe what the problem is?
Cover letter + date seems like fairly strong signal to me.

> so I strongly suggest that we do it the way b4 currently works:
> 
> - a series can start with RFC in the prefixes to indicate that it's not
>   something to be considered for inclusion
> - when the author feels that the series is ready for maintainers'
>   consideration, they simply drop the RFC and keep the same change-id and
>   versioning info; e.g. [PATCH RFC v3] -> [PATCH v4]

It's not a pain point for networking.

While I have you - it'd be great if the patchwork bot did not
repeatedly set patches to Superseded. Sometimes we want to keep and
apply non-latest version, because the latest version was posted based
on non-expert review, or we changed our mind.

> Resetting the versioning requires resetting the change-id of the series, or a
> lot of automation breaks.

What is "change-id of the series"?