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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Apr 14, 2021 at 06:57:13AM -0700, James Bottomley wrote:
> On Wed, 2021-04-14 at 08:49 -0300, Jason Gunthorpe wrote:
> > b4 does a nice job helping the maintainer, but the submitter has no
> > helpful common tooling currently.
> 
> We have git-format-patch/git-send-email. 

I think it is very poor. 

If you look at what a typical submitter has to deal with:

 - Make a series and write a cover letter. Version control the cover
   letter. In corporate cases many submitters should be getting internal
   review of everything, including the cover letter before sending.
   (Mostly I see people store the cover letter in git as an empty
   commit, easiest way to share for review)
 - Formulate the defined series and cover letter into a patch series
 - Annotate required To and CC's for the series and
   maintainers/reviewers. 

   Our tooling here is mediocre, we have get_maintainers but it is
   very hard to review/revise its output in the typical usage of just
   jamming it into git-send-email

   Little details like 'add the author and reviewers of the patches in
   the Fixes: lines' to the CC are often overlooked and are not
   automated.

   People seem to struggle to both narrow the CC list of individual
   patches series and still CC things like the cover letter to
   everyone.
 - Upload it to some public git so people can git fetch it
 - Submit it to SMTP, including using now required OAUTH. (Good luck!)
 - Keep a local copy of everything that was done.

 For v2:
 - Pull in all tags from the mailing list and update the git commits
   (b4 downloads the tags but doesn't automate fixing the local git
   branch)
 - Make required changes
 - Generate a change log and don't forget anything.

   git range-diff from the local copy of v1 is super helpful, but it
   is annoying to invoke git range-diff by hand.
 - Figure out the lore links of v1 to include in the cover letter
 - Revise the cover letter
 - Update the cc/to list to include discussion participants, people
   who gave reviewed-by/etc.
 - Send it again as v2

In all steps don't botch anything. Keep all the "state" related to the
submission in your head over a multiple weeks/months review cycle.

IMHO every single peice of information to drive the conversion of the
patch series to email should be stored in git itself, otherwise it
gets messed up/lost when it is revised/resent, and can't be reviewed
prior to submission.

git even makes very simple steps like editing the commit messages to
annotate tags/fix spelling overly difficult. Rebase with reword is a
pretty painfully way to do this.

The whole thing is quite hard and really time consuming - 'git
send-email' does almost none of what is needed and its operation of
relying on a huge list of unique command line arguments is not
effective.

I know people who send a lot of patches have their own custom work
flow scripts, but more casual people skip steps and do way too much
manual work, IMHO.

> description of git-format-email but I really think we should use more
> fields and make it automatic.  It would certainly be helpful if it
> tracked the last version sent of the same branch so I didn't have to
> add --version.  It can't, unfortunately, track message id's because
> that's generated by git-send-email (has to be that way because resends
> need different message id's).  

The thing invoking git-send-email can specify the message id, and it
can generate and track them using an acceptable algorithm. Other than
lacking OAUTH, git-send-email is an effective way to marshal a
directory of near-email format patches into SMTP.

For instance I've been using this algorithmic format for message id:

0-v1-6730d4ee0d32+40e6-gup_combine_put_jgg@nvidia.com
                       ^^^^^^^^^^^^^^^ my topic name
                  ^^^^ current time expressed as hex seconds since the
		       commit date
     ^^^^^^^^^^^^^ git commit in my tree that is at the top of what is
                   being sent
  ^^ Series sersion number
^  Patch number

Revises get new version numbers and new commit ids, resends get new
time stamps.

> The problem with the above is it's very fragile when done by two tools
> the latter of which might not be executed from the tree.  It really
> sounds like we need a combined tool for this, which includes the
> ability to resend patch series as well as to increment the version.

A single tool defaulting to supporting a narrow well defined
"acceptable" workflow would go along way to help the myriad of less
frequent submitters be more efficient.

Jason