Re: [PATCH 0/1] Clarify and expand description of --signoff

From: Jeff King <peff@peff.net>
Date: Oct 16, 2020, 01:59 UTC
Message-ID: <20201016015937.GA3335046@coredump.intra.peff.net>
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:

Show 19 quoted lines

> > > 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