Re: script to check "Fixes:" tags

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Fri, Sep 27, 2019 at 09:00:37PM +0200, Geert Uytterhoeven wrote:
> > I just noticed that checkpatch can handle a git range, so I'll revisit
> > it and see if I can "just test one thing" with it or not, next week.
> 
> That assumes the patches have been applied already...
> Which is fine for maintainers taking pull requests.

Or for maintainers who pull patches into a git repository for review
purposes.  For complex patches, or long patch series, it can be easier
to use Gerrit than reviewing patches in your inbox, because there's
not enough context in e-mailed diff.  So what I do get around this
problem when the patch series is sent via e-mail is to apply them onto
a temporary git branch.  That means I can look at the patch series in
the context of a whole tree.  It also means I can launch a smoke test
while I'm looking at the changes.

With modern review systems, the automatic build test, static code
checker runs, running uninit tests, etc., happen in parallel and
automatically the moment the patch(es) are submitted for review, even
before a human starts to pay attention to it.

Right now we're trying to simulate this by having the zero-day bot try
to guess what commit against which the patch or patch series are
applied.  Unnfortunately, sometimes the zero-day bot gets it wrong,
and recently it can take 4-5 days before the zero day bot goes through
its backlog, and today, the zero day bot doesn't know when a patch
series has been superceeded by a newer version, so it wastes CPU time
and generates noise on the mailing list.

So I can imagine a scheme where (optionally) a patch submitter would
push their patch series to some review queue, and the system would
e-mail the patches to the mailing list on behalf of the user.  In
parallel, build tests, regression tests could be run, checkpatch,
etc. could be run, etc., against that temporary git branch.

This has a number of advantages; newcomers won't have to fight with
their corporate e-mail systems to avoid white space damaging.  (This
can be quite challenging, and if their company is using Lotus Notes,
impossible.  :-)  It would also make it simpler for systems to run
tests against the branch, and could also enable some simplicity for
the test runners to be able to tell when the V20 version of a patch
series has been superceded by V21.

					- Ted