On Tue, Feb 23, 2016 at 04:31:35PM +0300, Dan Carpenter wrote:

Blergh...  You want it machine readable and I want it human readable.  I

Yeah. It's kind of tasting which may differ among people. I'll leave
the judgments to Junio and others, and only add necessary comments to
your points.

don't care so much about the cover letter but for the first patch then I
really want something minimal (one line) and human readable.

base tree/branch: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
base commit: afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
base patch-id: a849260a843115dbac4b1a330d44256ee6b16d7b
base patch-subject: Linux 4.4
base tag: v4.4

The necessary lines for the robot are

        base commit:
        base patch-id:
or
        base tree-id:
        base patch-id:

The "base tree-id" will be useful if the submitted patchset is based
on a public (maintainer) commit.

The "base patch-id" will be useful if the submitted patchset is based
on another patchset someone (likely the developer himself) posted to
the mailing list.

To me that looks like an unparseable wall of text.  My version of that
is:

Applies-to: afd2ff9b7e1b+ origin

As a human all I really want to know is the tree to apply this to.  If
it doesn't apply then I don't debug it, I just send an automatic note
"This doesn't apply to staging-next.  Please redo."

I think that Applies-to is a better name and also that grepping for
"^base " is less reliable than grepping for ^Applies-to.

Grep reliability should be the same, if you use "^base tree-id" and
"^base patch-id". If necessary, we can avoid white space by naming the
keys base-tree-id and base-patch-id.

I used "origin" because that's the name in Next/Trees.  The + means
private patches are applied.  That's what we already do in naming the
kernel.  If the + matters, then I would include a cover letter.

I have no idea what a "base patch-id" is so that doesn't work at all.

It'll come from this command 

        man git patch-id

It'll be useful if the patchset's base commit is a private one -- not
in any public maintainer tree, however the developer may have posted
it to LKML before.

The "base patch-id" can more reliably track different versions of
patches than "base patch-subject", and do not have the risk of
information leaking in case it's a confidential patch.

Including the tag is just duplicative since we already have the hash.

That's right. Just in case it's more human readable.

In my email, I proposed that we list all the other private patches in a
cover letter, but I think you are saying that we only need to know the
most recent private patch?

Yes in test robot POV. However it's a general git feature, so I guess
there will be more potential use cases and requirements.

Another idea would be to list them newest
to oldest (git log order instead of email order) in the cover letter.

Btw, I always work against linux-next and Dave M is always getting
annoyed with me for not marking which patches go to net and which go to
net-next.  I don't use git format-patch, but I will probably start using
"Applies-to: net" or "Applies-to: net-next".

As for now, I see the netdev ML has the convention

        [PATCH net]
        [PATCH net-next]

to tell Dave the target tree.

Thanks,
Fengguang