[antlr-interest] pull requests at github

[Benjamin S Wolf]

On Wed, Jul 11, 2012 at 4:00 PM, Terence Parr <parrt at cs.usfca.edu> wrote:
> So it looks like the intentions of the sign off line
>
> Signed-off-by: Random J Developer <random at developer.example.org>
>
> would go into the commit message so that it stays in the repository, as opposed to the pull request, right?
>
> apparently then there is an assumption that random J developer agrees with the developer's certificate of origin, but I don't like that from a legal point of view.

As far as I can tell, this is essentially what the linux kernel
project does: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD#l298
. I suppose you would want to specify somewhere prominent (e.g. the
pull request form, if possible) that adding the signoff to your commit
that you are certifying the Certificate of Origin.

On Thu, Jul 12, 2012 at 10:46 AM, Terence Parr <parrt at cs.usfca.edu> wrote:
> Hi guys, okay, I have another idea.
>
> Let's make a directory that's part of the source code itself that contains simple text documents with the language of the contributors license followed by the sign off line. Then, the commit hash for that document is the user's unique contributors ID. It's also unique in principle across all projects so the same user could sign a different contributors license for a different project.
>
>  During a commit, users would put their ID hash number into the comment and then I think github would automatically link to the document containing their signature.
>
> would that work? I think so. I also like the idea that I don't have to maintain the signatures anymore. They are just in the source code distribution.

I think using GUIDs and/or hash numbers is going a little overboard,
particularly when contributors are all github users, hence already
have a globally unique user id. I also think having one text file per
contributor is a little much as well, considering we only need a
signature.

My suggestion is to have one text file, with the Contributor's License
for the project, with a spot for contributors to digitally sign it,
where "digitally sign" = a commit that adds a line containing the
contributor's real name, github username, and email address (optional;
I guess it's not really necessary in this scheme). Thus the bar for
accepting a pull request by a contributor is, at a minimum: a) the
pull request contains a commit signing the license or the contributor
has already signed the license, and b) all other commits have the
signed-off-by line by the user submitting the pull request [and the
signed-off-by is a certification that it's all their code, etc etc.].
Someone who accepts the pull request will want to verify the
contributor has signed the license by checking for their name in the
license file.

The upside to this is that we don't need to add an opaque hex id that
github will recognize and linkify (but not local git) to each of our
commit messages; we'd only need to add the "-s" flag every time.
Really the only differences here are that we put all the signatures in
one file and not require a link to that commit from every future
commit. If we put that one file in the top level of the project, I
would posit (without being a lawyer) that that's just as effective.

I'm not actually sure how well github allows editing of commit
messages, but if possible, it should be simple to request that a new
contributor (who filed a pull request without doing all of this) sign
the license and add the commit to their pull request, and add the
signed-off-by message to their commits.