From: Nick Clifton Date: Wed, 19 Oct 2022 11:39:20 +0000 (+0100) Subject: Update MAINTAINERS file with details about accepting DCO signed contributions. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f2ba47d69ea5f0b7c16b9373b0c4c8942c7252aa;p=binutils-gdb.git Update MAINTAINERS file with details about accepting DCO signed contributions. * MAINTAINERS: Add section on patches, copyright and DCO. --- diff --git a/binutils/ChangeLog b/binutils/ChangeLog index 02c667a2762..807ac82a02f 100644 --- a/binutils/ChangeLog +++ b/binutils/ChangeLog @@ -1,7 +1,11 @@ +2022-10-19 Nick Clifton + + * MAINTAINERS: Add section on patches, copyright and DCO. + 2022-10-12 Nick Clifton PR 29665 - * objcopy.c (copy_object): Use the input filename when + * objcopy.c (copy_object): Use the input filename when reporting that a .gnu_debuglink section already exists. 2022-10-03 Nick Clifton diff --git a/binutils/MAINTAINERS b/binutils/MAINTAINERS index 3b60ac745f8..36c495e5a50 100644 --- a/binutils/MAINTAINERS +++ b/binutils/MAINTAINERS @@ -212,6 +212,35 @@ also blatantly obvious), and so on. Obvious fixes should always be small, the larger they are, the more likely it is that they contain some un-obvious side effect or consequence. +Obvious fixes should not be "legally significant", as defined here: + + https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant + + -------- Patches and Copyright --------- + +If a patch is non-obvious, its copyright must be considered. There +are two ways to handle this. The first is to assign the copyright +of the FSF. This ensures that if problems with the authorship of the +patch arise, the FSF will be able to deal with them. + +The list of already assigned copyrights can be obtained from +fencepost.gnu.org in the file: /gd/gnuorg/copyright.list. + +New copyright assignments can be obtained by completing one of the +forms found here and sending it off to the FSF: + + https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/Copyright + +The alternative is to sign off the contribution by agreeing to the +Developer's Certificate of Origin (version 1.1 or later) and adding a +line to the end of the contribution that looks something like this: + + Signed-off-by: Random J Developer + +The details of the Developer's Certificate or Origin can be found here: + + https://developercertificate.org/ + --------- Branch Checkins --------- If a patch is approved for check in to the mainline sources, it can