git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Stephen P Smith <ischis2@cox.net>
Cc: git@vger.kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH 1/3] Add 'human' date format
Date: Sun, 6 Jan 2019 01:19:36 -0500	[thread overview]
Message-ID: <20190106061935.GA4207@sigill.intra.peff.net> (raw)
In-Reply-To: <4462659.Bys67ThUBR@thunderbird>

On Fri, Jan 04, 2019 at 06:03:18AM -0700, Stephen P Smith wrote:

> On Friday, January 4, 2019 12:50:35 AM MST Jeff King wrote:
> > On Thu, Jan 03, 2019 at 06:19:56AM -0700, Stephen P. Smith wrote:
> > > 
> > > I didn't see anything in the code which would prohibit setting something
> > > like that.
> > 
> > Yeah, I don't think supporting that is too hard. I was thinking
> > something like this:
> 
> I take it that if I update Linus's patch, I still keep Junio's and Linus' 
> sign-off line for the purpose of the chain of custody?  Of should I use a 
> second patch?

I think the most interesting question is the actual authorship (i.e.,
the "From:" field).  I think people are generally OK with having their
patches polished a bit to fix obvious bugs or short-comings. But at some
point if you make too many changes they or may not want to have the
result attributed to them. ;)

For the particular change I suggested, it's borderline to me on whether
it hits that case, so I'd probably err on the side of caution. And I'd
either expect Linus to say "yeah, that sounds like a good direction", or
I'd do it as a separate patch. And if a separate patch, I'd probably
tease Linus's patch out into two separate ones: one to add "human", and
one to implement "auto". And then drop the "auto" one in favor of your
new patch (with you as the author).

And I think that makes the signoff questions go away for this instance
(keep the signoffs for Linus's, and just signoff the new patch
yourself). But here's some general pontificating in that direction:

    Normally you can just drop Junio's signoff. The chain of custody is
    usually "author, then maintainer" and he'll re-add his maintainer
    signoff when he picks up your patch. In this case of this patch it's
    "author, then polisher, then maintainer", but Junio is still at the
    end.

    Now one can argue that Junio picked up Linus's patch, which you then
    picked up from Junio's repository and fed back to Junio. But you
    could just as well have picked Linus's patch up from the mailing
    list and then polished it. So I don't know that having Junio twice
    in the chain is really that interesting.

    Generally, yes, I'd keep Linus's signoff in a situation like this.
    He is asserting that the original work done meets the DCO
    requirements. You polishing the patch does not change that (of
    course you could introduce a bunch of new code that doesn't meet the
    DCO and sign it off anyway, but that's why there's ordering in the
    chain of custody. Somebody investigating would probably walk
    backwards up the chain).

-Peff

  reply	other threads:[~2019-01-06  6:27 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-31  0:31 [PATCH 0/3] Add 'human' date format Stephen P. Smith
2018-12-31  0:31 ` [PATCH 1/3] " Stephen P. Smith
2019-01-03  7:37   ` Jeff King
2019-01-03 13:19     ` Stephen P. Smith
2019-01-04  7:50       ` Jeff King
2019-01-04 13:03         ` Stephen P Smith
2019-01-06  6:19           ` Jeff King [this message]
2018-12-31  0:31 ` [PATCH 2/3] Add 'human' date format documentation Stephen P. Smith
2018-12-31  0:31 ` [PATCH 3/3] t0006-date.sh: add `human` date format tests Stephen P. Smith
2019-01-02 18:15   ` Junio C Hamano
2019-01-03  2:36     ` Stephen & Linda Smith
2019-01-03  6:42       ` Junio C Hamano
2019-01-03 13:20         ` Stephen P. Smith
2019-01-03 21:14     ` Philip Oakley
2019-01-03 21:45       ` Junio C Hamano
2019-01-03 23:57         ` Stephen P. Smith
2019-01-03  7:44   ` Jeff King
2019-01-03 13:12     ` Stephen & Linda Smith
2019-01-08 21:27   ` Johannes Sixt
2019-01-09  0:44     ` Stephen P. Smith
2019-01-09  6:58       ` Johannes Sixt
2019-01-10  1:50         ` Stephen & Linda Smith
2019-01-18  6:18 ` [PATCH v2 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-18  6:18   ` [PATCH v2 1/5] Add 'human' date format Stephen P. Smith
2019-01-18  6:18   ` [PATCH v2 2/5] Remove the proposed use of auto as secondary way to specify human Stephen P. Smith
2019-01-18 18:35     ` Junio C Hamano
2019-01-19  3:44       ` Stephen & Linda Smith
2019-01-18  6:18   ` [PATCH v2 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-18 18:47     ` Junio C Hamano
2019-01-18  6:18   ` [PATCH v2 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-18 19:03     ` Junio C Hamano
2019-01-20 22:11       ` Stephen P. Smith
2019-01-22 18:29         ` Junio C Hamano
2019-01-18  6:18   ` [PATCH v2 5/5] Add `human` date format tests Stephen P. Smith
2019-01-18 19:24     ` Junio C Hamano
2019-01-21  5:31   ` [PATCH v3 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 1/5] Add 'human' date format Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 2/5] Replace the proposed 'auto' mode with 'auto:' Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-21  5:31     ` [PATCH v3 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-22 22:34       ` Junio C Hamano
2019-01-21  5:31     ` [PATCH v3 5/5] Add `human` date format tests Stephen P. Smith
2019-01-29  3:50     ` [PATCH v4 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 1/5] Add 'human' date format Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 2/5] Replace the proposed 'auto' mode with 'auto:' Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-29  3:50       ` [PATCH v4 5/5] Add `human` date format tests Stephen P. Smith
2019-01-21  5:16 ` [PATCH v3 0/5] Re-roll of 'human' date format patch set Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 1/5] Add 'human' date format Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 2/5] Replace the proposed 'auto' mode with 'auto:' Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 3/5] Add 'human' date format documentation Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 4/5] Add `human` format to test-tool Stephen P. Smith
2019-01-21  5:16   ` [PATCH v3 5/5] Add `human` date format tests Stephen P. Smith
2019-01-21 15:04     ` SZEDER Gábor
2019-01-22  0:53       ` Stephen & Linda Smith

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20190106061935.GA4207@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ischis2@cox.net \
    --cc=torvalds@linux-foundation.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).