The Project's codebase is maintained in shared information repositories using CVS on the xml.apache.org machine. Only Committers have write access to these repositories. Everyone has read access via anonymous CVS.
All Java Language source code in the repository must be written in
conformance to the
All source code committed to the Project's repositories must be
covered by the
Each of the Project's active source code repositories contain a file named STATUS which is used to keep track of the agenda and plans for work within that repository. The status file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual developers are working on or want discussion about, and anything else that may be useful to help the group track progress.
The active status files are automatically posted to the developer mailing lists three times per week.
Groups are allowed to create a branch for release cycles, etc. They are expected to merge completely back with the main branch as soon as their release cycle is complete.
Simple patches to fix bugs can be committed then reviewed. With a commit-then-review process, the Committer is trusted to have a high degree of confidence in the change.
Doubtful changes, new features, and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, the size of the program, configuration data formats, or other major areas must receive consensus approval before being committed.
Related changes should be committed as a group, or very closely together. Half complete projects should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the developer's platform before being committed.
The current source code tree for a subproject should be capable of complete compilation at all times. However, it is sometimes impossible for a developer on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message.
A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release.
When a specific change to a product is proposed for discussion or voting on the appropriate development mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary corresponding to the action item for that patch.
The patch should be created by using the diff -u command from the original software file(s) to the modified software file(s). For example:
diff -u Main.java.orig Main.java >> patchfile.txt
or
cvs diff -u Main.java >> patchfile.txt
All patches necessary to address an action item should be concatencated within a single patch message. If later modification to the patch proves necessary, the entire new patch should be posted and not just the difference between the two patches.