[antlr-interest] pull requests at github

[Sanne Grinovero]

Nice ideas.

To answer a question: yes with GitHub I'm allowed to edit my commits
in all parts even after having sent the pull request: including the
commit comments. It basically just points to the originating branch.

You can't customize the pull-request form, but GitHub allows to hook
your custom scripts in the repository, so you could optionally have a
script validate this requirement by an automated trigger and reject
the pull while it provides some instructions to the newcomer.

As an example, with Hibernate we use these event listeners to
automatically trigger Jenkins builds on pull requests and send a
notification to Twitter and IRC channels on successful integrations.

We also face the same problem of having to track which contributor has
already signed the contributor agreement; for that there is currently
no automation: we have a web form like the one for ANTLR,  which feeds
a list which we manually check when accepting patches. Isn't too bad
as most requests originate from the usual well known people.

It seems our legals are happy to have contributors sign only once,
there is no need to have them refer to the statement for each
subsequent commit. I would say indeed that if I sign a document
referring to "contributing" now and in the future, it would be a poor
defense later in future to deny having ever read that when sending
additional patches.

Regards,
Sanne

On 13 July 2012 09:36, Benjamin S Wolf <jokeserver at gmail.com> wrote:
> 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.
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address