Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state in rtl8366rb

[Jakub Kicinski <kuba@kernel.org>]

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