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$(echo .)org \
--cc=alsi@bang-olufsen$(echo .)dk \
--cc=andrew@lunn$(echo .)ch \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=f.fainelli@gmail$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=konstantin@linuxfoundation$(echo .)org \
--cc=krzk@kernel$(echo .)org \
--cc=linus.walleij@linaro$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=luizluca@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=olteanv@gmail$(echo .)com \
--cc=pabeni@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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