Difference between revisions of "Development Resources/Handling Git Contributions"

From Eclipsepedia

Jump to: navigation, search
(Gerrit)
Line 33: Line 33:
 
=Gerrit=
 
=Gerrit=
  
The process changes a bit for projects that use Gerrit Code Review
+
The process changes a bit for projects that use Gerrit Code Review.
 +
 
 +
Assumptions:
 +
* Contribution provides code for an ''existing'' Bugzilla record
 +
 
 +
Scenario:
  
 
# Contributor must create an account on eclipse.org and agree to the Contributor Agreement;
 
# Contributor must create an account on eclipse.org and agree to the Contributor Agreement;
 +
# Contributor creates a Git commit:
 +
#* Comment field contains reference to the Bugzilla record (e.g. Bug 12345); and
 +
#* Author email field set to contributor's eclipse.org email address.
 
# Contributor pushes their commit to the Git/Gerrit repository;
 
# Contributor pushes their commit to the Git/Gerrit repository;
# Project committer triages the commit:
+
# Project committer triages the commit; if a CQ is required:
#* Creates a CQ if required and attaches a patch generated from the Git commit;
+
#* Creates a CQ and attaches a patch generated from the Git commit;
#* When approved, committer reflects approval on the Gerrit record;
+
#* Asks contributor to assert on the corresponding bug that they:
# Required number of committers approve the commit;
+
#*# authored 100% the content they are contributing
# Commit is merged into HEAD:
+
#*# have the rights to donate the content to EPL
#* Author field is set to contributor's identity
+
#*# contribute the content under the EPL
 +
#* When approved, committer reflects approval on the Gerrit record (i.e. they flip the IP bit on);
 +
# Required number of committers approve the commit (this may vary by project);
 +
# Commit is merged into an appropriate branch by the committer
  
 
[[Category:Git]]
 
[[Category:Git]]

Revision as of 17:16, 20 January 2012

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.

Scenario

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. A contributor who is not currently a committer on the project indicates that they've authored some code that they'd like to contribute to the project (this may occur through any number of communication channels).
    • The developer who authored the code is referred to as the "contributor" or "author"
  2. Eclipse project committer agrees the contribution is something they would like to include in their project.
  3. Contributor (author) or project committer creates a bugzilla that include URL pointers to the refs (commit record) in the source repository.
  4. The contributor (author) provides a statement regarding the provenance, rights, and license of the code in a comment on the Bugzilla record.
    • e.g., "I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use."
  5. If required by the IP Due Diligence Process (e.g. if the contribution exceeds 250 lines), the committer creates a CQ (including the URL of the ref), attaches a patch, and waits for "check in" permission
  6. Project committer merges the pull request back into the eclipse.org project git repository.
    • The "Committer" name and email in the Git commit record must be set to the committer's information. The "email" field must be the Eclipse committer ID, or the committer email address as recorded for the committer account at the Eclipse Foundation. See Committing and Pushing for more information.
    • The "Author" name and email in the Git commit record must be set to the contributor's information. See How do I change the author of a commit in git? for help.
    • 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"
  7. Project committer adds a comment on the Bugzilla record that includes URL pointers to the refs in the eclipse.org repository
  8. Project committer closes the bug.

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:

  • Contribution provides code for an existing Bugzilla record

Scenario:

  1. Contributor must create an account on eclipse.org and agree to the Contributor Agreement;
  2. Contributor creates a Git commit:
    • Comment field contains reference to the Bugzilla record (e.g. Bug 12345); and
    • Author email field set to contributor's eclipse.org email address.
  3. Contributor pushes their commit to the Git/Gerrit repository;
  4. Project committer triages the commit; if a CQ is required:
    • Creates a CQ and attaches a patch generated from the Git commit;
    • Asks contributor to assert on the corresponding bug that they:
      1. authored 100% the content they are contributing
      2. have the rights to donate the content to EPL
      3. contribute the content under the EPL
    • When approved, committer reflects approval on the Gerrit record (i.e. they flip the IP bit on);
  5. Required number of committers approve the commit (this may vary by project);
  6. Commit is merged into an appropriate branch by the committer