Jump to: navigation, search

Difference between revisions of "Development Resources/Initial Contribution"

(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Before you begin, your project needs to be [[Development Resources/Project Provisioning|provisioned]]. As part of that process, your project will be given a code repository, access to the downloads server, etc. You and your other developers will also be given committer access; only committers can write code into your code repository. But before you start writing to the repository, your first contribution ("initial contribution") must be scrutinized by the Eclipse IP Team.
+
Before you can make an initial contribution, your project needs to be [[Development Resources/Project Provisioning|provisioned]]. As part of that process, your project will be given a code repository, access to the downloads server, etc. You and your other developers will also be given committer access; only committers can write code into your code repository. But before you start writing to the repository, your first contribution ("initial contribution") must be scrutinized by the Eclipse IP Team.
  
 
Before you begin, make sure that you are familiar with your top-level project's charter, and that the contribution aligns with the scope of that charter and the scope defined by your project. You should discuss the nature of the contribution with your project, parent project leadership (if any), and [[PMC]]. Your PMC will be required to authorize your contribution; socialization of the contribution will make the process run more smoothly.
 
Before you begin, make sure that you are familiar with your top-level project's charter, and that the contribution aligns with the scope of that charter and the scope defined by your project. You should discuss the nature of the contribution with your project, parent project leadership (if any), and [[PMC]]. Your PMC will be required to authorize your contribution; socialization of the contribution will make the process run more smoothly.
 +
 +
Incubating projects at Eclipse can take advantage of the [[Development Resources/HOWTO/Parallel IP Process|parallel IP process]] for contributions. With parallel IP, the IP team performs a rudimentary scan of the contribution and--based on their initial findings--authorizes check-in of the code. When that authorization is received, a project committer can commit the contribution into a project source repository and work can begin on the project code. Projects can generally get approved for parallel IP check in very quickly. It always depends on the depth of the IP team's work queue, but approval should come in a matter of a few days.
 +
 +
'''A project cannot make a release until the due diligence on the IP contained in that release is complete.'''
 +
 +
The due diligence can take a while, especially for a large code base that has a lot of contributors who need to be validated and potentially hunted down. There will almost certainly be some code hits that will need to be resolved. There will almost certainly be comments like "I stole|liberated this from XXX" in the code that need to be researched. There will also be third-party libraries to sort out. Unfortunately, it's pretty hard to quantify "a while", because it depends on many factors. An established code base with years of development by numerous developers may take months to work through the IP due diligence process. Smaller chunks of code may take days or weeks.
 +
 +
Please make sure that you are familiar with the [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse Due Diligence Process]. If you have any questions, please ask your PMC or project mentors.
  
 
To make your initial contribution:
 
To make your initial contribution:
  
#Wait until you receive notice from the Webmaster that your project has been provisioned
+
#Wait until you receive notice from the Webmaster that your project has been provisioned;
 
#Ensure that the namespace in your contribution aligns with Eclipse [[Naming Conventions|naming conventions]] (i.e. org.eclipse.<project-name>.*)
 
#Ensure that the namespace in your contribution aligns with Eclipse [[Naming Conventions|naming conventions]] (i.e. org.eclipse.<project-name>.*)
#*All all bundles and package names should be correct.
+
#*All bundles and package names must conform to the established conventions, and
#Make sure that you have the required [http://www.eclipse.org/legal/guidetolegaldoc.php notices]  
+
#*Be sure to rename extension-point ids and bundle Ids embedded in your code;
#*[[The about.html|about.html]], license files etc.
+
#Ensure that [http://www.eclipse.org/legal/copyrightandlicensenotice.php Eclipse copyright and license notice(s)] in the required form have been applied to source content including configuration files when possible (Note that the Eclipse project's [[Development Resources/How to Use Eclipse Copyright Tool|Copyright Tool]] can help you with copyright notices);
#Pack up the source code and attach it to a bugzilla record as "Initial Contribution" under your new project's bugzilla component
+
#Make sure that you have the required [http://www.eclipse.org/legal/guidetolegaldoc.php notices]:
#Then use the [http://portal.eclipse.org Foundation Portal] to open the CQ referencing this Bug.
+
#*[[The about.html|about.html]], license files etc.;
 +
#Pack up the source code and attach it to a Bugzilla record as "Initial Contribution" under your new project's Bugzilla component
 +
#*Ensure that there are no nested JARs or ZIP files in the content;
 +
#Then use the [http://portal.eclipse.org Foundation Portal] to open a "Contribution Questionnaire" (CQ) referencing this Bug; and
 +
#When you receive the email requesting you to do so, attach the same file to the CQ itself (the attachment must be made on both the Bugzilla bug and the IPZilla CQ).
 +
 
 +
Note that no nested jar files or zip files should be included in CQ attachment. Project-licensed content and third-party-licensed content are not reviewed together.  Separate CQs are required. Please familiarize yourself with the [http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf Eclipse Policy and Procedures for Third Party Dependencies]. Again, if you are uncertain, please ask your PMC or project mentors for assistance.
  
 
More information is available in [[Development Resources/New Commmitter Handbook|The New Committer Handbook]].
 
More information is available in [[Development Resources/New Commmitter Handbook|The New Committer Handbook]].

Revision as of 12:38, 8 November 2012

Before you can make an initial contribution, your project needs to be provisioned. As part of that process, your project will be given a code repository, access to the downloads server, etc. You and your other developers will also be given committer access; only committers can write code into your code repository. But before you start writing to the repository, your first contribution ("initial contribution") must be scrutinized by the Eclipse IP Team.

Before you begin, make sure that you are familiar with your top-level project's charter, and that the contribution aligns with the scope of that charter and the scope defined by your project. You should discuss the nature of the contribution with your project, parent project leadership (if any), and PMC. Your PMC will be required to authorize your contribution; socialization of the contribution will make the process run more smoothly.

Incubating projects at Eclipse can take advantage of the parallel IP process for contributions. With parallel IP, the IP team performs a rudimentary scan of the contribution and--based on their initial findings--authorizes check-in of the code. When that authorization is received, a project committer can commit the contribution into a project source repository and work can begin on the project code. Projects can generally get approved for parallel IP check in very quickly. It always depends on the depth of the IP team's work queue, but approval should come in a matter of a few days.

A project cannot make a release until the due diligence on the IP contained in that release is complete.

The due diligence can take a while, especially for a large code base that has a lot of contributors who need to be validated and potentially hunted down. There will almost certainly be some code hits that will need to be resolved. There will almost certainly be comments like "I stole|liberated this from XXX" in the code that need to be researched. There will also be third-party libraries to sort out. Unfortunately, it's pretty hard to quantify "a while", because it depends on many factors. An established code base with years of development by numerous developers may take months to work through the IP due diligence process. Smaller chunks of code may take days or weeks.

Please make sure that you are familiar with the Eclipse Due Diligence Process. If you have any questions, please ask your PMC or project mentors.

To make your initial contribution:

  1. Wait until you receive notice from the Webmaster that your project has been provisioned;
  2. Ensure that the namespace in your contribution aligns with Eclipse naming conventions (i.e. org.eclipse.<project-name>.*)
    • All bundles and package names must conform to the established conventions, and
    • Be sure to rename extension-point ids and bundle Ids embedded in your code;
  3. Ensure that Eclipse copyright and license notice(s) in the required form have been applied to source content including configuration files when possible (Note that the Eclipse project's Copyright Tool can help you with copyright notices);
  4. Make sure that you have the required notices:
  5. Pack up the source code and attach it to a Bugzilla record as "Initial Contribution" under your new project's Bugzilla component
    • Ensure that there are no nested JARs or ZIP files in the content;
  6. Then use the Foundation Portal to open a "Contribution Questionnaire" (CQ) referencing this Bug; and
  7. When you receive the email requesting you to do so, attach the same file to the CQ itself (the attachment must be made on both the Bugzilla bug and the IPZilla CQ).

Note that no nested jar files or zip files should be included in CQ attachment. Project-licensed content and third-party-licensed content are not reviewed together. Separate CQs are required. Please familiarize yourself with the Eclipse Policy and Procedures for Third Party Dependencies. Again, if you are uncertain, please ask your PMC or project mentors for assistance.

More information is available in The New Committer Handbook.