[GIT PULL] SafeSetID LSM changes for v5.8

[Micah Morton]

On Sun, Jun 14, 2020 at 11:39 AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> On Sun, Jun 14, 2020 at 11:04 AM Micah Morton <mortonm at chromium.org> wrote:
> >
> > I amended the author on the lone commit in this pull request. For some
> > reason I was thinking using the "From:" line in the commit body was
> > how I should make things show up as Thomas as the author and me as the
> > committer, but looks like that’s not true.
>
> That's how we do things in email, since you want a separate author for
> the emailed patch than from the author of the email itself.
>
> But git itself very much has that difference between "author" and
> "committer" internally, and all the usual email application tools will
> take the separate "From:" line from the email, and make that be the
> author in git.

Ah makes sense, thanks!

>
> (And then the sign-off chain is where we describe the whole path,
> because git only has the concept of those two end-points: the original
> author, and the final committer, but no concept of the path in between
> the two, nor does it have the concept of the copyright and license
> agreement implications of the sign-offs).
>
> > I also removed my own Signed-off-by line from the pull request body
> > and included it in the commit instead of the Reviewed-by line.
>
> Good. You will get credit for the pull request in the merge commit
> itself as a "Pull xyz from Micah Morton", so that path of history gets
> encoded that way.
>
> But the sign-off chain is supposed to be there for each individual commit.
>
> (I don't always notice those things, but afaik there is automation in
> place in -next that should warn about commits with incomplete sign-off
> chains. Did that not trigger for some reason in this case?).

This change hasn't had any bake time in linux-next. I didn't deem it
sufficiently risky or complex to warrant such integration testing.

That said I'm a little fuzzy on where to draw the line for which kinds
of changes really should be required to have bake time in -next. If
you think this is one of those cases, we can hold off on this until we
have some bake time for v5.9.

Either way this is a good reminder for the v5.9 merge window when we
plan to have more featureful changes going in for SafeSetID (although
those will be completely internal to the LSM, so low chance of
breaking anything outside the module).

>
>                   Linus