Re: RFC: Superseded-by: follow-up trailer

[Alex Elder <elder@ieee.org>]

On 4/13/21 4:40 PM, Konstantin Ryabitsev wrote:
> On Tue, Apr 13, 2021 at 05:29:01PM -0400, Steven Rostedt wrote:
>> Now, I would really like the Supercedes: tag, as its just a link you need,
>> and not a email sent. Ideally this would be in all the patches (with a
>> direct link to what it Supercedes. I may update my scripts to do exactly
>> this, as I always add a "Link: " to the last version, and that's in my
>> repo. Or perhaps b4 could add this too!
> 
> I'd rather folks used the following notation in the cover letter/patch
> basement:
> 
>      Previous versions:
> 
>      Link: https://lore.kernel.org/r/foo # v2
>      Link: https://lore.kernel.org/r/bar # v1

I had a few thoughts about this last night.  I hope this
isn't too rambly.

I haven't been using this to tie together versions of a
series.  But I think it's a good idea and I will start
(possibly after the dust settles on this discussion).
It implements at least part of what Doug Anderson sought
when he advocated including a Change-Id tag to track
related versions of patch series.

This practice is the developer's responsibility, not the
maintainer's.  I don't find that tracking the link down is a
very big burden.  And checkpatch.pl could be taught to look
for such links and suggest them for any version after the
first.  This probably isn't the "helpful common tooling"
that Jason Gunthorpe mentioned, but using checkpatch.pl is
a common expectation of developers.

I assume these links are pointing to the first message in
the series--which would be the cover letter assuming there
is one.  I have no interest in finding (or seeing) links
like this for every commit.  This suggests that developers
should always include a cover page for multi-patch series;
is that now required?

If this information is in the cover page, then maintainers
should preserve it by including the cover letter in the
merge commit.  I know this was a recent topic, but I didn't
follow it close enough to know whether that was the conclusion.

For single patches, I'd rather have the link be under the
"---", and have the link field added by the maintainer be
the only one committed.  I think I'd also prefer just
having a single link to the previous version, rather than
including a full and growing set of them in each version
(but that's only a slight preference).

> This is much more succinct, indicates the version number in the trailer, and
> removes the need to remember how to spell "Superseded", as there seems to be
> little consensus. :)

I retract my earlier spelling of that word.  Here too,
checkpatch.pl could ridicule anyone who spells it wrong and
we'll all figure it out eventually.

I like the succinctness of "Link:".  It is flexible enough
to be interpreted as a "see also" reference rather than
just "the patch submission correspondence is here."

On the other hand, it lacks specificity.  It's possible
that having distinct tags would be helpful for tools.

And finally I hope this practice (however it ends up looking)
is optional, to avoid adding yet another learning hurdle for
new developers.  Individual maintainers can require it or not
as a matter of their own policy.  I realize that reduces its
value.

					-Alex

> The tooling on the kernel.org side can automatically send the required
> follow-ups to previous threads when it finds these trailers in newer
> submissions.
> 
> -K
>