With the Crystal release being out of the door we will follow up on the previously mentioned goal to enforcement a Developer Certificate of Origin (DCO) on contributions to core ROS 2 repositories [1]. We will use the following GitHub App to automate the check: https://github.com/probot/dco
After having done some testing with dummy repositories we will enable this for actually used repositories. We will start with a few (from two different orgs, repos with frequent contributions) and will add more repositories over time if we are confident that the process works well:
In the beginning we won’t require passing the DCO check in order to give us the freedom to merge already existing and reviewed PRs. But in the near future it will be mandatory so please consider reading about how to sign your commits of future contributions: https://help.github.com/articles/signing-commits/ adding the Signed-off-by line to your commits now.
You can do either of the following:
invoke git commit with -s / --signoff to automatically add this line to your commit message
manually add a the line to each commit message, e.g. Signed-off-by: Your Name Developer <your.name@example.com>
create an alias in .gitconfig to append -s to each git commit invocation
create a commit.template which contains the Signed-off-by line to pre-populate interactive commit messages
In the linked post @gerkey doesn’t give a rationale, it contains merely a statement of intent:
We’re also working on updates to developer policies, such as enforcement of a Developer Certificate of Origin (DCO) on contributions to core ROS 2 repositories.
In short: (i) we decided to enforce a contribution mechanism because of strong support for doing so among industry partners generally over several years and among the ROS 2 TSC membership more specifically and recently; and (ii) we chose the DCO because it’s become a commonly accepted practice for open source projects. As compared to other mechanisms (e.g., a CLA), the DCO is the lightest-weight tool that appears to convince a large fraction of the likely corporate stakeholders (and more importantly, their respective lawyers) that it’s OK to use the output from and contribute to a project.
The goal here is to do the right thing with respect to preventing inappropriate contributions while having a minimal impact on the development workflow. FWIW we almost enabled a CLA for ROS 2 a few years back, but the tools weren’t sufficient at the time to avoid having a bunch of manual steps; e.g., requiring people with commit rights to be checking github usernames against a spreadsheet before merging their PRs (we tried CLAHub, but it wasn’t quite ready yet).
Are there any plans to move to a CLA in the future? It would give the ROS TSC more freedom over the code than the DCO appears to, although I imagine that would be negatively perceived by some people.
I’m not disagreeing with that decision, but I’m interested in knowing the basis for that envision. Brian’s explanation seems mainly to pertain to the state of things a few years ago and starting simple.
In the mean time we have enabled the DCO check to a number of repositories (see https://github.com/ros2/ros2cli/pull/210#issuecomment-474900128 for the complete list) and added a note about the DCO to the CONTRIBUTING.md file to each of these repositories.
