Welcome, New Committers!To get started:
How We Keep In TouchThe team keeps in touch on a day-to-day basis via the development list and Skype. We generally try to keep significant discussions on the list, but prefer Skype for higher-bandwidth discussions. We also have weekly, virtual Committer Meetings where we discuss our recent work on the FCRepo project. This also gives us a way to share what we're doing with interested members of the community (the meeting minutes are public). Generally, committers employed by Fedora Commons are present at these meetings, and committers from other organizations may attend as their time allows. What To Work OnWhile 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 want to work on a new feature that isn't in the FCREPO tracker yet, please feel free to submit it, and open it if it's an obvious bug or improvement that needs work. If not, leave it in the "Received" state – this will trigger a discussion of the issue in an upcoming Fedora Developer Meeting. Claiming an IssueOnce 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, 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
Working in a BranchIf you're a new committer, or you're working on a substantial body of code, you should create a branch to work on it. Here's a guide to branching in subversion if you're not already familiar. Branches should be created as fedora/branches/fcrepo-123, where "fcrepo-123 is the JIRA id of the issue you're working on. 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 TrunkWhether 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. Soon after you commit a change to the trunk, a set of automated tests will begin running on our test server. You should get an email within an hour indicating whether the test succeeded or failed. If the tests failed, other developers will be notified via the codewatch list so that they know not to do a "svn update" until you have committed a fix. Closing an IssueOnce the relevant code has been committed and passes the automated tests, you can resolve the issue in JIRA. Prior to resolving an issue, double check to make sure the metadata is accurate in the tracker. How we do ReleasesSee the Fedora Release Process document. |