[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240311-chowchow-of-premium-piety-9e4a0d@lemur>
Date: Mon, 11 Mar 2024 14:40:44 -0400
From: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To: Jakub Kicinski <kuba@...nel.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, 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, 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]
Resetting the versioning requires resetting the change-id of the series, or a
lot of automation breaks.
-K
Powered by blists - more mailing lists