From: Jakub Kicinski <kuba@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: "Krzysztof Kozlowski" <krzk@kernel.org>,
"Simon Horman" <horms@kernel.org>,
"Luiz Angelo Daros de Luca" <luizluca@gmail.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state in rtl8366rb
Date: Mon, 11 Mar 2024 11:52:28 -0700 [thread overview]
Message-ID: <20240311115228.5ad9db52@kernel.org> (raw)
In-Reply-To: <20240311-chowchow-of-premium-piety-9e4a0d@lemur>
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"?
next prev parent reply other threads:[~2024-03-11 18:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-10 4:51 [PATCH net-next 0/4] net: dsa: realtek: fix LED support for rtl8366 Luiz Angelo Daros de Luca
2024-03-10 4:51 ` [PATCH net-next 1/4] dt-bindings: net: dsa: realtek: describe LED usage Luiz Angelo Daros de Luca
2024-03-10 8:34 ` Krzysztof Kozlowski
2024-03-21 11:56 ` Luiz Angelo Daros de Luca
2024-03-21 12:18 ` Krzysztof Kozlowski
2024-03-24 2:10 ` Luiz Angelo Daros de Luca
2024-03-25 7:41 ` Krzysztof Kozlowski
2024-03-10 18:02 ` Andrew Lunn
2024-03-21 12:03 ` Luiz Angelo Daros de Luca
2024-03-10 18:31 ` Linus Walleij
2024-03-21 11:57 ` Luiz Angelo Daros de Luca
2024-03-10 18:52 ` Andrew Lunn
2024-03-21 11:58 ` Luiz Angelo Daros de Luca
2024-03-10 23:08 ` Rob Herring
2024-03-21 12:00 ` Luiz Angelo Daros de Luca
2024-03-10 4:51 ` [PATCH net-next 2/4] net: dsa: realtek: keep default LED state in rtl8366rb Luiz Angelo Daros de Luca
2024-03-10 8:01 ` Krzysztof Kozlowski
2024-03-10 11:37 ` Simon Horman
2024-03-10 11:47 ` Krzysztof Kozlowski
2024-03-11 16:11 ` Jakub Kicinski
2024-03-11 16:19 ` Krzysztof Kozlowski
2024-03-11 17:14 ` Jakub Kicinski
2024-03-11 18:40 ` Konstantin Ryabitsev
2024-03-11 18:52 ` Jakub Kicinski [this message]
2024-03-11 19:11 ` Konstantin Ryabitsev
2024-03-10 4:52 ` [PATCH net-next 3/4] net: dsa: realtek: do not assert reset on remove Luiz Angelo Daros de Luca
2024-03-10 18:33 ` Linus Walleij
2024-03-10 4:52 ` [PATCH net-next 4/4] net: dsa: realtek: add LED drivers for rtl8366rb Luiz Angelo Daros de Luca
2024-03-10 8:02 ` Krzysztof Kozlowski
2024-03-10 11:49 ` Simon Horman
2024-03-24 2:31 ` Luiz Angelo Daros de Luca
2024-03-10 18:47 ` Andrew Lunn
2024-03-24 3:46 ` Luiz Angelo Daros de Luca
2024-03-24 15:32 ` Andrew Lunn
2024-03-25 2:50 ` Luiz Angelo Daros de Luca
2024-03-25 12:38 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240311115228.5ad9db52@kernel.org \
--to=kuba@kernel.org \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=horms@kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).