Re: [kernel.org users] b4: encouraging using the cover letter in merge commits?

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

On Sat, 2020-12-19 at 18:43 -0300, Arnaldo Carvalho de Melo wrote:
> Em Sat, Dec 19, 2020 at 01:01:43PM -0800, James Bottomley escreveu:
> > On Sat, 2020-12-19 at 17:48 -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Sat, Dec 19, 2020 at 11:03:59AM -0800, James Bottomley
> > > escreveu:
> > > > On Sat, 2020-12-19 at 11:57 -0700, Jonathan Corbet wrote:
> > [...]
> > > > > We're getting into minor details, though.  If The Community
> > > > > were to decide somehow that link tags are The Preferred Way,
> > > > > I would not kick and scream too hard before going along with
> > > > > it.  Unless I were in one of my screaming moods at the time,
> > > > > of course.
> > > > 
> > > > I'm not really seeking a preferred way, I'm just asking why
> > > > people who now use the link tag and linear series should
> > > > change.  As long as we can agree the link tag is fine and
> > > > there's really no additional information that needs capturing,
> > > > I think we can leave it to maintainer discretion whether they
> > > > prefer merge per series or linear.
> > > 
> > > My question is: is the information in the cover letter useful? 
> > 
> > I think it is but it's not vital to understanding individual
> > commits, which should be properly described.
> 
> Agreed.
>  
> > > If it is, why not have it preserved in the main repo?
> > 
> > Because the link tag supplies it and works with current linear
> > workflows.  To mandate storing the cover letter, people using
> > linear workflows have to move to a new method.
> 
> But that points to outside the main repository.

Yes, but I don't see this as a problem.  The whole point of having
infrastructure which dereferences msgid links is that we can use it.

If this is an argument about having all the information in the repo, I
really don't think it's worth it.  All the nuance is stored in the
email trail, so simply pointing at it seems far easier.  Also, however
carefully you harvest the cover letter and relevant details into the
merge commit, you'll always miss something sometimes.  I think even net
admits this by doing both cover letter and link tag.

> > >  The owner of such repositories asks us to describe what is in
> > > the series, sign it, and then this gets dropped?
>  
> > Um, well we don't have people sign the cover letter.  We just have
> > it describe the current series and its history.  Plus it doesn't
> > get dropped ... it's in the email history, pointed to by the link
> > tag, which is often a lot richer than the bare cover letter anyway.
> 
> I agree the link tag is valuable, but it points to outside the repo.
>  
> > The main point is we have two pieces of information:  The precise
> > description of what each commit does, which should be in the
> > tree.  And
> 
> I often have this problem with submitters: things that should be at
> individual commits are grouped in the cover letter, makes my life
> harder, as I'll end up having more work to do to move that to where
> it belong: individual commits.

Well, we tend to make them do a rewrite.  Although I have to confess a
lot of it, after upteen iterations of commit messages which reproduce
the C code in slightly different English each time, becomes "get the
series into shape and we'll write the commit text for you" (or in the
case of SCSI, Martin will rewrite the commit message for you ...).

But the danger of having the cover letter is precisely that you are
less apt to be strict about the commit message, which can be confusing
for someone else when looking for a bug because they'll be going on the
commit text.

> But we are digressing, assuming what is in the cover letter is not
> what should be in individual commits but has value, why not have it
> preserved upstream?

Because on its own it's incomplete and we have other mechanisms to keep
the full historical record.

James