git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Philippe Blain <levraiphilippeblain@gmail.com>,
	"Bradley M. Kuhn" <bkuhn@sfconservancy.org>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH 0/1] Clarify and expand description of --signoff
Date: Thu, 15 Oct 2020 21:59:37 -0400	[thread overview]
Message-ID: <20201016015937.GA3335046@coredump.intra.peff.net> (raw)
In-Reply-To: <CAPc5daWenXds=0BW0CXa=4MOF2UxDeQ8DF2+7V9-WkKwCFCDBw@mail.gmail.com>

On Thu, Oct 15, 2020 at 06:54:30PM -0700, Junio C Hamano wrote:

> > > Documentation/git-commit.txt    | 13 ++++++++-----
> > > Documentation/merge-options.txt | 13 ++++++++-----
> > > 2 files changed, 16 insertions(+), 10 deletions(-)
> >
> > Since the changes are exactly the same in the two files, maybe
> > a preparatory patch that creates 'signoff.txt' and includes it
> > in 'git-commit.txt' and 'merge-options.txt' would be a good idea ?
> 
> I actually think we are OK with two duplicated and leave that for
> later clean-up. The more important would be to polish the text into
> a good enough state quickly.
> 
> Another thing we should not forget is to update our SubmittingPatches
> document. Since we are placing extra stress on that there is NO
> inherent meaning in "sign off" and it is largely up to each project,
> we should set a good example explaining what it means to THIS
> project to sign your patches off, and SubmittingPatches is the
> document to do so. Without such an update, I think the update
> to these two files we see in this patch is incomplete.

I agree we should be leading by example here.

We do already say pretty clearly what signed-off-by means in the
project:

  $ grep -A14 '\[\[sign-off]]' Documentation/SubmittingPatches 
  [[sign-off]]
  === Certify your work by adding your "Signed-off-by: " line
  
  To improve tracking of who did what, we've borrowed the
  "sign-off" procedure from the Linux kernel project on patches
  that are being emailed around.  Although core Git is a lot
  smaller project it is a good discipline to follow it.
  
  The sign-off is a simple line at the end of the explanation for
  the patch, which certifies that you wrote it or otherwise have
  the right to pass it on as an open-source patch.  The rules are
  pretty simple: if you can certify the below D-C-O:
  
  [[dco]]
  .Developer's Certificate of Origin 1.1

What should we change there? We could perhaps bring up signoffs earlier
or more prominently. Or tie it in to the git-commit docs by saying
explicitly: these are _our_ project rules for signoffs.

-Peff

  reply	other threads:[~2020-10-16  1:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 21:59 [PATCH 0/1] Clarify and expand description of --signoff Bradley M. Kuhn
2020-10-15 21:59 ` [PATCH 1/1] Documentation: " Bradley M. Kuhn
2020-10-16  0:46   ` Jeff King
2020-10-18 15:13   ` Theodore Y. Ts'o
2020-10-16  1:49 ` [PATCH 0/1] " Philippe Blain
2020-10-16  1:54   ` Junio C Hamano
2020-10-16  1:59     ` Jeff King [this message]
2020-10-16  2:30       ` Junio C Hamano
2020-10-16 19:53         ` Junio C Hamano
2020-10-16 20:11           ` Jeff King
2020-10-17  3:00             ` Bradley M. Kuhn
2020-10-18 19:08             ` Junio C Hamano
2020-10-19 15:53               ` Theodore Y. Ts'o
2020-10-19 18:26                 ` Junio C Hamano
2020-10-19 21:25                   ` [PATCH v2 0/3] clarify and expand description of --signoff & related fixes Bradley M. Kuhn
2020-10-19 21:25                     ` [PATCH v2 1/3] Documentation: clarify and expand description of --signoff Bradley M. Kuhn
2020-10-19 21:25                     ` [PATCH v2 2/3] Documentation: stylistically normalize references to Signed-off-by: Bradley M. Kuhn
2020-10-19 22:02                       ` Taylor Blau
2020-10-19 22:17                         ` Junio C Hamano
2020-10-20  2:31                           ` Taylor Blau
2020-10-20  1:03                         ` [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by Bradley M. Kuhn
2020-10-20  1:03                           ` [PATCH v3 1/4] doc: preparatory clean-up of description on the sign-off option Bradley M. Kuhn
2020-10-20  1:03                           ` [PATCH v3 2/4] Documentation: clarify and expand description of --signoff Bradley M. Kuhn
2020-10-20 21:44                             ` Bradley M. Kuhn
2020-10-20 21:48                               ` Taylor Blau
2020-10-20  1:03                           ` [PATCH v3 3/4] SubmittingPatches: clarify DCO is our --signoff rule Bradley M. Kuhn
2020-10-20  1:03                           ` [PATCH v3 4/4] Documentation: stylistically normalize references to Signed-off-by: Bradley M. Kuhn
2020-10-20 18:52                             ` Junio C Hamano
2020-10-20 21:33                               ` Bradley M. Kuhn
2020-10-20  2:34                           ` [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by Taylor Blau
2020-10-20 21:28                             ` Bradley M. Kuhn
2020-10-20 21:48                               ` Taylor Blau
2020-10-20 22:06                               ` Junio C Hamano
2020-10-20 23:02                                 ` Bradley M. Kuhn
2020-10-19 21:25                     ` [PATCH v2 3/3] SubmittingPatches: clarify DCO is our --signoff rule Bradley M. Kuhn
2020-10-18 19:49 [PATCH v2 0/3] Claryfing the meaning of the sign-off Junio C Hamano
2020-10-18 19:49 ` [PATCH v2 1/3] doc: preparatory clean-up of description on the sign-off option Junio C Hamano
2020-10-18 19:49 ` [PATCH v2 2/3] Documentation: clarify and expand description of --signoff Junio C Hamano
2020-10-18 19:49 ` [PATCH v2 3/3] SubmittingPatches: clarify DCO is our --signoff rule Junio C Hamano
2020-10-18 23:31 ` [PATCH v2 0/3] Claryfing the meaning of the sign-off Taylor Blau

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=20201016015937.GA3335046@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=bkuhn@sfconservancy.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=levraiphilippeblain@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 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 NNTP newsgroup(s).