...
While we collectively prefer the high-priority tracker items (as determined by the user community and committers) to be worked on first, all contributions are appreciated. You may work on any unclaimed items that exist in the FCREPO tracker in JIRA. If you have verified a pre-existing bug notice an FCREPO-related bug report/feature request in the Community Support Tracker, please move it to the FCREPO tracker before starting the work. If you have identified and verified a new bug, you may submit it directly to the FCREPO tracker.
If you want to work on a new feature that isn't in the FCREPO tracker yet, please bring it up on the development list or in the Committer Meeting so we can discuss talk about the benefit of the feature and how it fits with the software.
Claiming an Issue
Once you have an issue to work on, simply assign yourself as the owner in JIRA. This lets everyone know that you plan to begin working on the issue soon. If you find that you cannot complete an issue, please you should 1) remove yourself as the owner to give other developers an opportunity to work on it and 2) if you've created a branch for it, remove the branch.
Coding Guidelines
- Code Style
The project's coding style is currently best described by the Eclipse settings in src/build. Here are the major rules:- Four space indents, spaces, NO TABS
- K&R style braces
- Dont use wildcard imports
- Write Javadocs for public methods and classes. Keep it short and to the point.
- Avoid public instance variables; use accessors.
- Use public methods sparingly; implementation details are not public.
- Logging
We currently use Log4J for logging. This may change in the future, but until it does, please be consistent. When writing log messages (especially INFO, FATAL, and WARN), consider your audience. Don't over-use INFO; these messages are always logged by default. - Testing
Use JUnit for unit, integration, and system tests. When making changes, please take the time to write tests as needed. We are not looking for 100% coverage here, but the developers will have a lot more confidence in your code if you can show that it works. See the readme.txt in the root of the source tree as a jumping-off point for adding your tests to one of the suites. Here's a brief description of the basic types of tests we run:- Unit - Tests a single class. These tests are typically very quick to run, and therefore get the most use by developers. Unit tests don't touch the disk or interface with classes other than mocks. If you can cover a scenario adequately in a unit test, you should prefer implementing it as such (and not as an integration or system test)
- Integration - Tests multiple classes working together. May touch disk or interact with a "test" database.
- System - Works against a running Fedora server in a given configuration. These are "block box" style tests against the public APIs of Fedora. These take much longer to run than unit or integration tests because they require significant setup.
...
When it's time to merge your branch down to trunk, you may request a review by another committer. Request a review via email, then assign them as the reviewer for the issue (or Code Task) in JIRA and click "Start Review". When the reviewer is finished, they'll let you know so you can merge your branch down to trunk.
When you've successfully merged your branch, it's useful life is over. You should therefore remove it from the /branches directory in subversion.
Committing to Trunk
Whether you're merging down from a branch or making changes directly to the trunk, you should be reasonably certain that your change won't break existing code. One way to quickly check is to run "ant junit" prior to check-in. If you're still not sure, you may also run several of the system tests as described in the readme.txt in the root of the source tree.
...