Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Development Resources/Handling Git Contributions"
| Line 1: | Line 1: | ||
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. | 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. In the meantime, we have to bridge the old world with the new. | ||
=Scenario= | =Scenario= | ||
| Line 6: | Line 10: | ||
# Eclipse project committer agrees the contribution is something they would like to include in their project. | # Eclipse project committer agrees the contribution is something they would like to include in their project. | ||
| − | # Contributor or project committer creates a bugzilla that includes a URL pointer to the commit record in the source repository. | + | # Contributor or project committer creates a bugzilla that includes a URL pointer to the ref (commit record) in the source repository. |
| − | # | + | #* e.g., https://github.com/waynebeaton/KittyMunch3/commit/d08bf60f7de9a5e6b48823a115d8054f2a871819 |
# The contributor provides a statement regarding the provenance, rights, and license of the code: | # The contributor provides a statement regarding the provenance, rights, and license of the code: | ||
| − | #* "I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use." | + | #* 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." |
| − | # If required by the IP Due Diligence Process (e.g. if the contribution exceeds 250 lines), the committer creates a CQ and waits for "check in" permission | + | # 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) and waits for "check in" permission |
# Project committer merges the pull request back into the eclipse.org project git repository. | # Project committer merges the pull request back into the eclipse.org project git repository. | ||
| − | # | + | # Project committer sets the Bugzilla record's URL field to the URL of the ref in the eclipse.org repository |
| − | + | #* e.g., http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=0e184beca9dacdc26ec009dbc54be108a5c5723e | |
| − | + | #* Project committer closes the bug. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 15:37, 18 February 2011
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. 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.
- Eclipse project committer agrees the contribution is something they would like to include in their project.
- Contributor or project committer creates a bugzilla that includes a URL pointer to the ref (commit record) in the source repository.
- The contributor provides a statement regarding the provenance, rights, and license of the code:
- 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."
- 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) and waits for "check in" permission
- Project committer merges the pull request back into the eclipse.org project git repository.
- Project committer sets the Bugzilla record's URL field to the URL of the ref in the eclipse.org repository
- e.g., http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=0e184beca9dacdc26ec009dbc54be108a5c5723e
- Project committer closes the bug.