Re: [PATCH 1/7] xz: add fall-through comments to a switch statement

[Ian Jackson <iwj@xenproject.org>]

Julien Grall writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch statement"):
> On 06/12/2021 16:12, Jan Beulich wrote:
> > Hmm, I did address both your and Ian's concerns in v2, admittedly by only
> > going as far as minimally necessary. I therefore wouldn't call this an
> > "open objection".
> 
> I believe my objection is still open. I still have have no way to verify 
> what you did is correct.

I can't believe this is still outstanding.  I think I understand
Julien's position, and I agree with what I have understood.

In particular, I think I understand why Julien feels it necessary to
make an issue of this.  The Signed-off-by lines are there to help
provide assurance that we aren't making legal mistakes.  They need to
be verifiable by a reviewer.  So that means that when a patch's own
declaration of its origin is "this patch came from Linux commit XYZ"
then all the S-o-b in that Linux git commit should be retained.

If the patch came from somewhere else, eg a mailing list post, I think
it would be OK to say something like "this patch came from lmkl, [url
to posting], and has since been committed to Linux as [commitid]~".
In that case the S-o-b should match the mailing list posting, but the
Xen patch being posted must then be identical to the mailing list
posting.

IOW it should be a deterministic process to start with the patch's
declaration of where it came from (or which sources it came from), and
verify that 1. the patch really did come from there and 2. all of the
approriate tags, especially S-o-b, are present.

By far the easiest way to achieve this is to take the patch from Linux
git using (eg) git-cherry-pick.  git will automatically DTRT. [1]

I don't have as strong an opinion about other tags, eg ones indicating
approval in Linux.  However, I think the overwhelming majority of
people would think it conventional to transfer all of the tags from
the original commit even if they are irrelevant in the new context.



I don't understand Jan's position.

Jan, why are you fighting so hard to delete these tags ?  What
practical harm does its presence do ?


[1] Jan, I know that you don't use git very much.  I think this is a
great shame.  I find it perplexing to see how anyone can work without
it.  The git command line UI is indeed terrible, but by now almost
everyone has either bitten the bullet of learning it, or adopted one
of the overlay UI packages that now exist.  (Personally I did learn
the cli but am starting to forget git cli nonsence since now I do
almost everything with magit inside emacs.)

I think the time has long passed when it is reasonable for a key Xen
developer to ask others to do additional work, or deal with anomalies,
in order to accomodate an unwillingness to use git.  Obviously we all
have our own workflows, but git has heavily influenced our shared
norms (and data formats).  If someone chooses not to use git, they
must at least be able to pretend.


Sorry,
Ian.