Welcome, New Committers!
Before getting started, we'd like to have your formal permission to distribute your contributions. To make this process easy, we can take an emailed copy of your signed CLA. For further instructions, see the Fedora Commons Licenses Page.
...
To get started:
- Send the following information to cwilper (at) fedora-commons.org:
- Your fedora-commons.org userid (If you don't have one, create one here). This is used to grant you committer-level permission on the resources hosted on our main website (JIRA, Confluence, Bamboo, etc)
- Your sourceforge.net userid (If you don't have one, create one here). The code repository is currently hosted at sourceforge.net, so we need your userid there in order to grant you write access.
- If you're a Skype user, your Skype userid. If you don't use Skype, please provide a phone #.
- Sign up to the Fedora Development list.
- Sign up to the Fedora Codewatch list using your userid@sourceforge.net address. This is a public list that all committers subscribe to. It's used solely for automatic notification of Subversion commits and automated test results. It is necessary to sign up using your sourceforge.net id; commit notification will not work otherwise. Make sure you have set up your Sourceforge account so that emails to userid@sourceforge.net are forwarded to your usual address.
- Get familiar with compiling and testing Fedora. Pay special attention to the section on setting up Eclipse. Our current coding conventions are embodied by the settings you will import into Eclipse.
How We Keep In Touch
The 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.
...
Once 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 Releases
We try to put out regular releases every few months. Once a release date is decided, we continue our work on the trunk until about a week before the release. At this point, we enter "code freeze". Code freeze officially starts when the release branch is created. This will be named "release-x.y.z" according to the release number. The purpose of this branch is to give us a stable reference point for our final tests. The only changes that should occur on this branch are show-stopper bugfixes and non-code-related edits.
If everything has gone according to plan, a final build is packaged and put into the download area on Sourceforge on release day. The release branch is then tagged and merged down to trunk.