Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2019-07-02 at 09:39 -0600, Shuah Khan wrote:
> On 7/2/19 9:18 AM, James Bottomley wrote:
> > On Tue, 2019-07-02 at 08:10 -0700, James Bottomley wrote:
> > > On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
> > 
> > [...]
> > > > People who use the link tag today have their homebrewn scripts
> > > > to add them automatically and it shouldn't be rocket science to
> > > > add that to git, patchwork whatever.
> > > 
> > > So if we find a way of automating this globally, I'm completely
> > > happy. However, I would also note that whatever script does this
> > > could likely also be run by you after the fact to generate the
> > > back link, so foolproof automation also lessens the need to make
> > > this a mandatory commit tag.
> > 
> > Just on this one, it looks like getting git to archive the msgid of
> > the patch commit would assist any script that goes off and tries to
> > find patch series and its precursors in the archives, so perhaps
> > adding that would be the actionable change in all of this?
> > 
> 
> Looks like two things are emerging from my original thread that aimed
> to get clarification on including "Patch revision information" in
> commit logs.
> 
> 1. Judiciously including information from the "Patch revision info."
>     in the commit log could be valuable. Don't just bloat the commit
>     log with trivial change history. This is part of patch review
>     process and will not require any scripting. Maybe an update to
>     the patch submit guidelines documents.

Agree, as long as it's what Thomas and I have been discussing: namely
keeping the version information below the --- permanent history cutoff,
so it's visible to reviewers but won't become part of the permanent
patch history when the patch is committed to git.

I think the bit we're still arguing about is the link to prior series
as part of this below the line version history.  I agree it's useful,
but I also think it would be a burden to enforce for every patch
series.

> 2. Archiving msgid of the patch commit for reference. This one would
>     require some scripting to make it easier for maintainers.

Yes, I think we all agree on this.  The real question is how.  If we
make git do it, I think trivially Message-Id: can become part of the
optional metadata.  Or we could all use commit hooks that add a link
tag.  Personally I prefer the former because it would be universally
done with no effort but I recognise it would take time to get the
ecosystem change to propagate.

James

> There two aren't mutually exclusive and are actionable. Let's distill
> the thread discussion to the above two items as we discuss further.
> 
> thanks,
> -- Shuah
> 
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>