Who uses Signed-off-by and DCO?

Who uses Signed-off-by and DCO?

[Nanako Shiraishi]

git provides options and configuration variables to easily handle the Signed-off-by tag line. It is used to certify that the sender certifies the patch with the Developer's Certificate of Origin.

I have read SubmittingPatches document and understand this convention is used by the Linux Kernel Project.

I was giving a git introduction to students in my lab, and this question came up from one of them. How widely is this convention used? Are there projects other than the Linux Kernel and git itself?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: Who uses Signed-off-by and DCO?

[Andreas Ericsson]

Nanako Shiraishi wrote:
> git provides options and configuration variables to easily handle the
> Signed-off-by tag line. It is used to certify that the sender
> certifies the patch with the Developer's Certificate of Origin.
> 
> I have read SubmittingPatches document and understand this convention
> is used by the Linux Kernel Project.
> 
> I was giving a git introduction to students in my lab, and this
> question came up from one of them. How widely is this convention
> used? Are there projects other than the Linux Kernel and git itself?
> 

We use it for our own opensource projects, though I must admit we
stole the idea from git.git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Who uses Signed-off-by and DCO?

[Ben Walton]

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

Excerpts from Andreas Ericsson's message of Fri Jun 12 07:05:14 -0400 2009:
> > I was giving a git introduction to students in my lab, and this
> > question came up from one of them. How widely is this convention
> > used? Are there projects other than the Linux Kernel and git itself?
> > 
> 
> We use it for our own opensource projects, though I must admit we
> stole the idea from git.git.

We're using it for shared admin edits.  The author is root (or
whatever the shared account happens to be in other cases) and the SoB
is the admin that made the change.  It's not enforced by anything
other than convention, but it's still helpful for us.

-Ben

-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Who uses Signed-off-by and DCO?

[Jeff King]

On Fri, Jun 12, 2009 at 07:58:50AM -0400, Ben Walton wrote:

> We're using it for shared admin edits.  The author is root (or
> whatever the shared account happens to be in other cases) and the SoB
> is the admin that made the change.  It's not enforced by anything
> other than convention, but it's still helpful for us.

Out of curiosity, how do you set the SoB? Does each user do it manually
when making a commit?

Is there a particular reason to favor this over setting GIT_AUTHOR_NAME
and GIT_AUTHOR_EMAIL (this would lose the fact that the commit was made
from the shared account, but has better tool support for finding changes
by a given author)?

-Peff

Re: Who uses Signed-off-by and DCO?

[Ben Walton]

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

Excerpts from Jeff King's message of Fri Jun 12 10:48:57 -0400 2009:
> [any reason not to keep this on the git list?]

...no, I just forget to set the CC.

> On Fri, Jun 12, 2009 at 10:36:46AM -0400, Ben Walton wrote:
> 
> > I've aliased 'ci' to 'commit -s', and people either use the alias or
> > are encouraged to add the -s (it is by convention only, after all).
> > We've then setup the root shell such that $USER is leveraged to source
> > in some personalized shell when su is used.  This is where we set
> > GIT_COMMITTER_* on a per-admin basis.  People not doing that edit the
> > SoB line while editing the commit message...this fails with 'ci -m'.
> 
> Makes sense. I have a similar setup where people could be identified by
> the ssh keys they use to log in, but I have never gotten around to
> setting up something automated.
> 
> I suspect SoB may be more convenient than GIT_AUTHOR_* in your scenario
> just because you can tweak the former in the editor, as you note (and it
> sounds like it's possible to not have the other variables set up
> properly in your setup).

It is easier from that perspective, but since nothing is forcing the
use of -s, we'd have the same compliance if we wanted to ask people to
use --author (or set the proper environment).

> > Actually, I'm still wavering on which I'd prefer.  At this point,
> > since git is still fairly new for us in this capacity, we're feeling
> > our way through things.  I went with COMMITTER instead of AUTHOR
> > though since that tends to stand out more in `git log` (at least to my
> > eyes).  Since we're not a finger pointing group :), things like `git
> 
> I would argue that you should do the opposite. AUTHOR is really about
> "who wrote this change" and COMMITTER is about "who put this change into
> the repo". So to me, "Bob wrote the change, logged in as root@box2, and
> committed" should be AUTHOR=Bob, COMMITTER=root@box2.

Your described usage is more semantically correct.  It may make sense
for us to switch to AUTHOR, so that in the future we could pinpoint
changes with less hassle.  I'll be discussing this with my colleagues
shortly.

> But I am coming at it from the perspective that the author is of more
> interest. Finger-pointing aside, I find asking the author is the best
> thing to do when the commit message doesn't quite explain why a change
> was made. But if you think the shared account used to commit is of more
> interest, then it does probably make sense to mark it as the author.

Yes, that's a good point.  We're trying to get in the habit of
referencing ticket id's in commit logs as well, which does mitigate
bad commit messages somewhat.  It doesn't help when a change isn't
driven by a ticket though.

> > blame` aren't typically used in this scenario.  We're more interested
> > in moving away from a `cp -p $file $file.date.initials` style of
> > version control.  (Yes, I know...)
> 
> I think we've all been there. ;)

We're currently testing etckeeper on a few boxes with git as the
backend so that we can move away from individual repos too.  One
stumbling block for us here is that we have a mixed shop and solaris
seems to grow etc directories all over the place! :) etckeeper has a
-d option, but that gets annoying to remember.

> > Some of our other shared projects are managed through gitosis repos,
> > so this doesn't come into play, as people edit the files in their own
> > accounts and push to the central area.  We have our bind config and
> > zones managed this way.  The files are published to our dns servers
> > after a push iff `named-checkconf -z` passes.
> 
> I have tried this, too, but it can get annoying very quickly. In order
> to really deploy and test you have to commit, which discourages quick
> "is this config right?" testing. Which is maybe a good thing on
> production servers, but sometimes you need to do some trial and error to
> diagnose a configuration problem.

In our case, it's not that onerous, since our config is fairly static
in terms of new zones, etc.  I've mitigated this for my own repo by
having a pre-commit hook run named-checkconf too...it's a fast check
so it doesn't hurt much.  If it's clean on my box, it'll be clean on
the servers too, since we're on the same versions of the software.
Any real config problems or major upgrades would be handled with test
environments too, so we're not normally worried about test changes
with this.

Having bad changes kicked out before they're made live has been nice,
although in practice they don't happen that often.  We'd likely be
better served to ensure that changed zone files have newer serials
than the live versions..

Previously, we made changes directly to the copy of the files that
cfengine distributed, so bad edits were seen by the live boxes.  With
this setup, we can still make semantic errors, but syntax problems are
gone.

We don't use this technique for things that lend themselves more to
'quick test' style changes (like adding a new input to our cfengine
setup).  Things aren't typically committed to these repos until the
change is verified though.  This keeps our history cleaner, which is
nice when we're not leveraging branches and personal working copies
and all the other really strong points of git.

Git is making our lives easier, but as you can see, we're still in a
state of flux wrt best practices, etc.

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Who uses Signed-off-by and DCO?

[Brandon Casey]

Ben Walton wrote:
> Excerpts from Jeff King's message of Fri Jun 12 10:48:57 -0400 2009:
>> [any reason not to keep this on the git list?]
> 
> ...no, I just forget to set the CC.
> 
>> On Fri, Jun 12, 2009 at 10:36:46AM -0400, Ben Walton wrote:
>>
>>> I've aliased 'ci' to 'commit -s', and people either use the alias or
>>> are encouraged to add the -s (it is by convention only, after all).
>>> We've then setup the root shell such that $USER is leveraged to source
>>> in some personalized shell when su is used.  This is where we set
>>> GIT_COMMITTER_* on a per-admin basis.  People not doing that edit the
>>> SoB line while editing the commit message...this fails with 'ci -m'.
>> Makes sense. I have a similar setup where people could be identified by
>> the ssh keys they use to log in, but I have never gotten around to
>> setting up something automated.
>>
>> I suspect SoB may be more convenient than GIT_AUTHOR_* in your scenario
>> just because you can tweak the former in the editor, as you note (and it
>> sounds like it's possible to not have the other variables set up
>> properly in your setup).
> 
> It is easier from that perspective, but since nothing is forcing the
> use of -s, we'd have the same compliance if we wanted to ask people to
> use --author (or set the proper environment).
> 
>>> Actually, I'm still wavering on which I'd prefer.  At this point,
>>> since git is still fairly new for us in this capacity, we're feeling
>>> our way through things.  I went with COMMITTER instead of AUTHOR
>>> though since that tends to stand out more in `git log` (at least to my
>>> eyes).  Since we're not a finger pointing group :), things like `git
>> I would argue that you should do the opposite. AUTHOR is really about
>> "who wrote this change" and COMMITTER is about "who put this change into
>> the repo". So to me, "Bob wrote the change, logged in as root@box2, and
>> committed" should be AUTHOR=Bob, COMMITTER=root@box2.
> 
> Your described usage is more semantically correct.  It may make sense
> for us to switch to AUTHOR, so that in the future we could pinpoint
> changes with less hassle.  I'll be discussing this with my colleagues
> shortly.

We use a shared account for updating a specific git repository.  I have
this bit of shell in the .bash_profile of that account to automatically
prompt and set GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL when someone tries
"git commit':


_setup_git_ident ()
{
   local userid
   local ypentry

   while read -p "Your Real Login ID (not \"$LOGNAME\")> " userid
   do
       ypentry=$(ypmatch "$userid" passwd) || continue
       break
   done

   oldIFS=$IFS
   IFS=:
   set -- $ypentry
   IFS=$oldIFS

   GIT_AUTHOR_NAME=${GIT_AUTHOR_NAME:-"$5"}
   GIT_AUTHOR_EMAIL=${GIT_AUTHOR_EMAIL:-"$1@"$(dnsdomainname)}

   export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
}

_run_git ()
{
   if [ "x$1" = "xcommit" ] &&
      [ -z "$GIT_AUTHOR_NAME" -o -z "$GIT_AUTHOR_EMAIL" ]
   then
       _setup_git_ident
   fi

   git "$@"
}

alias git=_run_git

Re: Who uses Signed-off-by and DCO?

[Jacob Helwig]

On Thu, Jun 11, 2009 at 16:42, Nanako Shiraishi<nanako3@lavabit.com> wrote:
> git provides options and configuration variables to easily handle the Signed-off-by tag line. It is used to certify that the sender certifies the patch with the Developer's Certificate of Origin.
>
> I have read SubmittingPatches document and understand this convention is used by the Linux Kernel Project.
>
> I was giving a git introduction to students in my lab, and this question came up from one of them. How widely is this convention used? Are there projects other than the Linux Kernel and git itself?
>
> --
> Nanako Shiraishi
> http://ivory.ap.teacup.com/nanako3/
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

GitHub uses it for the Fork Queue.  Whenever you pull in someone's
changes through the Fork Queue, it will add a SOB line for the person
pulling in the changes.  In this case it appears to be an "I approve
these incoming changes", instead of the DCO.  I honestly couldn't say
how common it is for projects that aren't on GitHub to use the SOB in
this manner, however.

Re: Who uses Signed-off-by and DCO?

[Scott Chacon]

Hey,

On Fri, Jun 12, 2009 at 7:56 AM, Jacob Helwig<jacob.helwig@gmail.com> wrote:
> GitHub uses it for the Fork Queue.  Whenever you pull in someone's
> changes through the Fork Queue, it will add a SOB line for the person
> pulling in the changes.  In this case it appears to be an "I approve
> these incoming changes", instead of the DCO.  I honestly couldn't say
> how common it is for projects that aren't on GitHub to use the SOB in
> this manner, however.

It has been pointed out that this is not consistent with how other
projects used SOB - we will probably remove this feature, or at least
add a checkbox or something instead in the near future.  FYI.

Scott

Re: Who uses Signed-off-by and DCO?

[Theodore Tso]

On Fri, Jun 12, 2009 at 08:42:07AM +0900, Nanako Shiraishi wrote:
> git provides options and configuration variables to easily handle
> the Signed-off-by tag line. It is used to certify that the sender
> certifies the patch with the Developer's Certificate of Origin.
> 
> I have read SubmittingPatches document and understand this
> convention is used by the Linux Kernel Project.
> 
> I was giving a git introduction to students in my lab, and this
> question came up from one of them. How widely is this convention
> used? Are there projects other than the Linux Kernel and git itself?

E2fsprogs uses the DCO convetion as well.

					- Ted

Re: Who uses Signed-off-by and DCO?

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> On Fri, Jun 12, 2009 at 08:42:07AM +0900, Nanako Shiraishi wrote:
>> git provides options and configuration variables to easily handle
>> the Signed-off-by tag line. It is used to certify that the sender
>> certifies the patch with the Developer's Certificate of Origin.
>> 
>> I have read SubmittingPatches document and understand this
>> convention is used by the Linux Kernel Project.
>> 
>> I was giving a git introduction to students in my lab, and this
>> question came up from one of them. How widely is this convention
>> used? Are there projects other than the Linux Kernel and git itself?
>
> E2fsprogs uses the DCO convetion as well.

True; I do not know if it counts as "other than the Kernel project"
in the original question, though.

Re: Who uses Signed-off-by and DCO?

[Theodore Tso]

On Fri, Jun 12, 2009 at 05:59:40PM -0700, Junio C Hamano wrote:
> >
> > E2fsprogs uses the DCO convetion as well.
> 
> True; I do not know if it counts as "other than the Kernel project"
> in the original question, though.

It depends on how you define "the Kernel project", I suppose.
E2fsprogs is built on a wide variety of platforms, including the GNU
Hurd, FreeBSD, Solaris, and others.  So is it part of the "[Linux]
Kernel project"?

I suppose util-linux-ng might be a closer call (it also uses the DCO
convention) as it is pretty well Linux-specific.  The developer
community of util-linux-ng is primarily not composed of kernel
developers, however, although there is some overlap.

BTW, some of the X.org git repositories also seem to be using DCO,
although its usage seems to be a bit spotty.

					- Ted

Re: Who uses Signed-off-by and DCO?

[Uwe Kleine-König]

On Fri, Jun 12, 2009 at 08:42:07AM +0900, Nanako Shiraishi wrote:
> I was giving a git introduction to students in my lab, and this
> question came up from one of them. How widely is this convention used?
> Are there projects other than the Linux Kernel and git itself?
I know ptxdist[1] and topgit[2].

Best regards
Uwe

[1] http://pengutronix.de/software/ptxdist/index_en.html
[2] http://repo.or.cz/w/topgit.git

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Re: Who uses Signed-off-by and DCO?

[David Aguilar]

On Sat, Jun 13, 2009 at 08:00:18PM +0200, Uwe Kleine-König wrote:
> On Fri, Jun 12, 2009 at 08:42:07AM +0900, Nanako Shiraishi wrote:
> > I was giving a git introduction to students in my lab, and this
> > question came up from one of them. How widely is this convention used?
> > Are there projects other than the Linux Kernel and git itself?
> I know ptxdist[1] and topgit[2].
> 
> Best regards
> Uwe
> 
> [1] http://pengutronix.de/software/ptxdist/index_en.html
> [2] http://repo.or.cz/w/topgit.git

git-cola [1] does.

I learned it by watching git ;-)

Multiple sign-off lines are useful for tracking code
reviews as well, as it's done on git and the kernel.

I've seen various flavors along those lines:

	Signed-Off-By: ...
	Tested-By: ... ($platform)
	Acked-By: ...
	Reviewed-By: ...

[1] http://cola.tuxfamily.org/

-- 
		David