All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Adam Borowski <kilobyte@angband.pl>,
	Ian Molton <spyro2@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Problematic culture around Signed-off-by
Date: Mon, 31 Jul 2017 15:58:40 +0200	[thread overview]
Message-ID: <20170731135840.GA9165@amd> (raw)
In-Reply-To: <20170731134449.gjdaiopb2m63jc23@node.shutemov.name>

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

On Mon 2017-07-31 16:44:49, Kirill A. Shutemov wrote:
> On Mon, Jul 31, 2017 at 03:34:11PM +0200, Adam Borowski wrote:
> > 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).

Yes, so you point up the breakage in the changelog...

> > > 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.
> 
> I use (and saw other people used) "Not-Yet-Signed-off-by:" for this
> purpose.

As I tried to explain, that is problematic.

If I fix the patch, how do I submit it myself?

But you are free to use Subject: [Not ready], or just sprinkle code
with // comments...

Anyway, applying not-ready patch is not something I usually seen
happening. OTOH, not applying patches that were ready months ago is
quite common :-).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

      reply	other threads:[~2017-07-31 13:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 11:40 Problematic culture around Signed-off-by Ian Molton
2017-07-30 18:52 ` Pavel Machek
2017-07-31 13:34   ` Adam Borowski
2017-07-31 13:44     ` Kirill A. Shutemov
2017-07-31 13:58       ` Pavel Machek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170731135840.GA9165@amd \
    --to=pavel@ucw.cz \
    --cc=kilobyte@angband.pl \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spyro2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.