[PATCH v12 net-next 0/9] add support for VSC7512 control over SPI

[Vladimir Oltean]

On Tue, Jul 05, 2022 at 01:30:15PM -0700, Colin Foster wrote:
> > Not all that useful as a changelog. I have no idea what I told you as 
> > that was probably 100s of reviews ago. When writing changelogs for patch 
> > revisions, you need to describe what changed. And it's best to put that 
> > into the relevant patch. IOW, I want to know what I said to change so I 
> > know what I need to look at again in particular.
> > 
> > And now that I've found v11, 'suggestions from Rob' isn't really 
> > accurate as you fixed errors reported by running the tools.
> > 
> > Rob
> 
> Good point - I'll be more clear going forward.

I have to say I agree with Rob, and no, you weren't more clear in the
v13 you've just posted.

First, you need to understand that a patch set with 13 revisions is on
the long side. You can't honestly expect reviewers' attention span to
last months.

Now, ok, you're at v13 already, entropy goes forward, what can you do.

First, you can link to previous versions in the cover letter, and also
parallel series containing sub-groups of patches. This information needs
to be carried throughout. I spent too long tracking your patch set
numbering system, with change sets that sometimes cover DSA and
sometimes don't, then they sometimes fork into separate series.
I lost track, let's put it this way. I'm not an expert, but I spent my
fair share of time with VSC751X datasheets and I am theoretically aware
what this patch set is trying to do, but I'm still lost.

Then, each patch needs to contain a version history of its own, in
between the "---" marker and the git short stat. Look at other patch
sets for examples. This must contain a description of the delta compared
to the previous version, including commit message rewording.

In extreme cases of large patch sets with essentially minimal changes
from version to version, maybe even the output of "git range-diff" could
be considered to be posted in the cover letter (that's rare though, but
it might help).

Generally, what you want to avoid is changing your mind in the middle of
a long patch set, especially without traceability (without being asked
to do so). Traceability here also means including links to review
feedback asking to make a design change. It may also help if you reply
to your own patch sets stating that you've found a problem in your own
code, and that you're thinking about solving it in this or that way,
even if you don't intend to get any reply.

You may even try to ask someone whom you're not working very closely
with to proof-read your patch sets and get an honest feedback "hey, are
you even following what I'm saying here? could you summarize why I'm
making the changes I'm making, and is this series generally progressing
towards a resolve?"

You got some feedback at v11 (I believe) from Jakub about reposting too
soon. The phrasing was relatively rude and I'm not sure that you got the
central idea right. Large patch sets are generally less welcome when
submitted back to back compared to small ones, but they still need to be
posted frequent enough to not lose reviewers' attention. And small
fixups to fix a build as module are not going to make a huge difference
when reviewing, so it's best not to dig your own grave by gratuitously
bumping the version number just for a compilation fix. Again, replying
to your own patch saying "X was supposed to be Y, otherwise please go on
reviewing", may help.

Also, ordering. I don't necessarily care what changed between v1 and v2
when you post v13. So you could start with the changelog for v13 and go
back in time from there, so that reviewers don't have to scroll more and
more for each revision.