This page details how to review contributions submitted for Apache Jena, it is intended primarily for Jena committers but is also useful in helping contributors understand what we expect from a contribution.
When reviewing contributed patches to Jena the committers are going to be considered the following:
Including tests is almost always a must for a patch unless the patch is for non-code content e.g. CMS diffs, maven config tweaks.
Tests are essential for bug fixes but should be considered mandatory for any patch. Jena uses JUnit for tests and uses the standard Java src/test/ directory conventions within its modules.
Code for inclusion in Jena should contain Apache copyright headers, only the contributor should remove/change copyright headers so if a different copyright header is present then you must request that the contributor change the copyright headers.
While this is not essential the Jena PMC have agreed not to maintain @author tags in the code since generally authorship can be identified from the SVN history anyway and over time committers will typically touch much code even if only briefly and in minor ways.
@author tags will not prevent a contribution being accepted but should be removed by the committer who integrates the contribution.
The Apache License states that any contribution to an Apache project is automatically considered to be contributed to the Apache foundation and thus liable for inclusion in an Apache project unless the contributor explicitly states otherwise.
Generally you will not have to worry about this but if anyone ever states that code is not for inclusion then we must abide by that or request that they make a statement that they are contributing the code to Apache.
Small patches can generally be incorporated immediately, larger patches - particularly those adding significant features - should usually be discussed on the dev@jena.apache.org list prior to acceptance.
Use your judgement here, a few hundred lines of code may be considered small if it isn't changing/extending functionality significantly. Conversely a small patch that changes a core behavior should be more widely discussed.
If in doubt start a thread on dev or comment on the JIRA issue, JIRA comments get copied to the dev list so all developers should see the comments even if they aren't explicitly watching the issue.
Depending on where a patch comes from there may be IP clearance issues, for small patches this is generally a non-issue. Where this comes into play is when a large patch is coming in which has been developed completely externally to Jena, particularly if that patch has been developed for/on behalf of a company rather than be developers working in their free time.
For patches like this we may require that the company in question submit a CCLA and that the developers involve submit ICLAs. There may also need to be IP Clearance vote called on the developer list to give developers a chance to review the code and check that there isn't anything being incorporated that violates Apache policy.
