Re: RFC: using supersedes: trailer to indicate patch/series revision flow

[Andrew Donnellan <ajd@linux.ibm.com>]

On 8/11/19 7:43 am, Konstantin Ryabitsev wrote:
> Questions:
> 
> 1. Should this be exposed via git-format-patch flags, or just used by    
> specialized tooling?

I guess we might want to expose it through git format-patch for the sake 
of completeness? Though if people actually use it with git format-patch, 
then the answer to Q2 is irrelevant because people will use it to link 
to whatever the heck they feel like at the time...

Though what do you envision the user workflow actually looking like with 
a specialised tool?

> 2. Should supersedes: link to the previous version of the patch, or the 
>     first ever version of the patch? I am leaning towards the latter,    
> even though in this case the message-id largely becomes identical in    
> usage to Gerrit's Change-Id.

If we link to the first version of the patch, we can't tell that V3 
supersedes V2. Though if we link to only the previous version, we can't 
tell that V3 supersedes V1 without looking at V2.

 From a Patchwork perspective, if we were to use this to track patch 
versions I think we could work with either, except for some corner cases 
where mail is not received or received in the wrong order and there's 
not enough subject metadata to work things out.

You could also include multiple trailers e.g. the first version and last 
version, or all previous versions that are superseded, though that seems 
a bit verbose.

> 3. Should the supersedes trailer have:
>     a. message-id without brackets
>     b. message-id with brackets
>     c. https://lore.kernel.org/r/message-id
>     My preference is b, to match with The Message-Id header usage.

A or B makes the most sense.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited