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.
Users will not find or understand new feature if there is no documentation.
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.
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.
Jena does not have a particular formal code style specification, but here are some simple tips for keeping your contribution in good order:
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.
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 email@example.com 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.
A pull request is a single unit so a large number of commits details the evolution internally but does not help record the external contribution.
Consider asking the contributor to merge commits into a few with useful messages for an external reviewer.
Project Processes including: