Re: Problematic culture around Signed-off-by

[Adam Borowski]

On Sun, Jul 30, 2017 at 08:52:36PM +0200, Pavel Machek wrote:
> > I've been away from kernel development for a bit, but I've returned and
> > I'm troubled by what seems to be an entrenched and widespread (IMO)
> > misuse of the "Signed-off-by:" in commits.
> > 
> > I've now either been asked to sign off RFC quality patches "because its
> > quicker" on more than one occasion in the last week or so, and I've seen
> > others signing off code which clearly has no hope of going anywhere near
> > the kernel. (eg. // commented out lines)
> > 
> > I was of the impression that Signed-off-by: was intended to be used on
> > essentially *finished* commits, indicating both readiness for inclusion
> > upstream and ones ownership of the copyright.
> > 
> > Even if the intent is *purely* a copyright isue, Signing off
> > *everything* surely makes it far too easy for people to get junk into
> > the kernel.
> 
> I normally sign-off everything... because getting patch without
> sign-off is nasty. If maintainer gets unclean, but signed-off patch,
> he can just clean it up, add his sign-off and continue normally.

Yet there are cases with known but unobvious breakage (see below).

> That may or may not be allowed if patch is not signed-off. (We are in
> lawyer teritory now.)
> 
> So I'd recommend signing everything, and if patch is considered "not
> ready", make it clear in some other way.

I think it'd be much better if you could suggest a new marker.  Something
like "Copyright-but-not-Readiness-Signed-off-by:", "RFC-Signed-off-by:",
"WIP-Signed-off-by:", etc.

And having a common, agreed upon marker would avoid confusion.

For example, I'm currently messing with a patch set that appears to give a
nice speed-up for the O_PONIES issue, but it messes with parts of the kernel
I'm really unfamiliar with.  Moreover, I know of data-loss scenarios in my
current version (I have naive ideas for a fix), but these scenarios are
irrelevant for a RFC.  Thus, it's imperative these patches do not get into
any non-experimental tree -- yet it's also likely that, if the concept
proves as good as it seems, that one of kernel devs with more skill would
take my work and beat it into sanity.

Cases like this just scream for a "Here-be-Dragons-but-Signed-off-Copyright-
Wise:" line.


Meow!
-- 
âââââââ What Would Jesus Do, MUD/MMORPG edition:
âââââââ â multiplay with an admin char to benefit your mortal
âââââââ â abuse item cloning bugs (the five fishes + two breads affair)
âââââââ â use glitches to walk on water