Revision as of 13:35, 18 June 2013

Git makes it easy to pull contributions from other repositories and make them part of your own. It feels wrong to do the same thing we do with CVS: attach a patch that is later added to the repository by a committer. The natural thing to do in Git is to pull the contribution in question from the contributor's Git repository. Regardless of the mechanism used to actually get the code into an Eclipse project's Git repository, the Eclipse IP Policy and Due Diligence Process must be followed.

One of the main issues that we need to address is that we need to form a connection between code that has been contributed and a statement of provenance, rights, and licensing. You know, lawyer stuff.

Git does a great job of keeping track of author information, but there is no built in way to keep track of all the other stuff. At some point in the hopefully-not-too-distant-future, we'll be able to use Gerrit for this (see Bug 283749). In the meantime, we have to bridge the old world with the new.

Git

An individual has forked one of the eclipse.org projects and has issued a pull request for a commit record that they would like to contribute to the eclipse.org project.

1. Contributor creates an Eclipse Foundation account and signs the Contributor Agreement
   • An Eclipse Foundation account can be created on any of forges managed by the Eclipse Foundation (projects.eclipse.org, locationtech.org);
2. Contributor creates a Git commit:
   • Author email address must set to the address associated with the author's Eclipse Foundation account;
   • Author must "Sign-off"; on the commit; the "Signed-off-by" credentials must match the author credentials;
   • Additional authors may be listed by including "Also-by: {Author Name} <{email}>" entries in the commit comment; and
   • If the contribution is associated with a Bugzilla record, cite that record in the commit message (e.g. Bug 12345);
3. Contributor connects with the project via a transparent communication channel (e.g. project mailing list, forum, or Bugzilla record) to indicate that they've authored some code that they'd like to contribute to the project:
   • Contributor provides a link to the contribution's ref for a "Git pull";
4. Project committer initiated IP Due Diligence process:
   • If a CQ is required, the committer creates a CQ and attaches a patch generated from the Git commit; and
   • Committer waits for check-in authorization
5. Project committer merges the commit record into one of the project's Git repositories:
   • In simple cases, pull requests can be merged into your local Git repositories as follows:
     • Add the contributor's Git repository as a remote, e.g. "git remote add <contributor-name> <contributor's repository URL>"
     • Fetch the latest from the contributor's repository: "git fetch <contributor-name>"
     • Cherry-pick the commit mentioned in the pull request: "git cherry-pick <hash of commit>"
     • Confirm that the generated commit has the correct content, and the correct metadata: "git show HEAD", "git log --pretty=full"

Note that the automated IP Log generator has been updated to include contributions made through Git (see bug 327594). If Git contributions have the author field correctly set, there is no need to mark the Bugzilla entry iplog+; in fact, doing so may result in redundant entries in the log.

Gerrit

The process changes a bit for projects that use Gerrit Code Review.

Assumptions:

• The contributor is not a project committer;
• A user may have multiple email addresses registered with Gerrit; and
• All of these addresses can be used to identify the user (generally via the Author Email field).

Scenario:

1. Contributor creates an Eclipse Foundation account and signs the Contributor Agreement
   • An Eclipse Foundation account can be created on any of forges managed by the Eclipse Foundation (projects.eclipse.org, locationtech.org);
2. Contributor creates a Git commit:
   • Author email address must set to the address associated with the author's Eclipse Foundation account;
   • Author must "Sign-off"; on the commit; the "Signed-off-by" credentials must match the author credentials;
   • Additional authors may be listed by including "Also-by: {Author Name} <{email}>" entries in the commit comment; and
   • If the contribution is associated with a Bugzilla record, cite that record in the commit message (e.g. Bug 12345);
3. Contributor pushes their commit to the Gerrit repository;
4. Project committer works with contributor to revise (if necessary) the contribution and otherwise shape it into a form that can be accepted by the project;
5. Required number of committers approve the commit (this may vary by project);
6. Project committer initiated IP Due Diligence process:
   • If a CQ is required, the committer creates a CQ and attaches a patch generated from the Git commit;
   • Committer waits for check-in;
   • When approved, committer reflects approval on the Gerrit record (i.e. they flip the IP bit on).
7. Commit is merged into an appropriate branch by the committer

Notes:

• The IP Due diligence process permits for certain contributions for work done "under the supervision of the PMC". The definition of "under the supervision of the PMC" varies from PMC to PMC, but is generally accepted to mean that the work is within the scope of the project plan and/or the contribution is a patch for an existing bug/issue.
• A contribution provided through Gerrit does not necessarily have a corresponding record in Bugzilla. If such a record does exist, it should be cited on in the commit message.
• A this point in time, we require that the contributor explicitly consent to the Terms of Use when an account is created.
• Project committers can push commits from contributors. Each individual commit record is subject to the terms outlined above.
• Starting in July 2013, Gerrit will be configured to enforce these requirements.