Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Send the following information to cwilper (at) duraspace.org:
    • Your fedora-commonsduraspace.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 # and/or Instant Messaging info.
  2. Sign up to the Fedora Development list.
  3. 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.
  4. Get familiar with compiling and testing Fedora.

...

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 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 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 talk about the benefit of the feature and how it fitsfeel 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 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, 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.

...

Branches should be created as fedora/branches/fcrepo-123, where "fcrepo-123 is the JIRA id of the issue you're working on.Sometimes it's convenient to work on multiple issues in a single development branch.  In these cases, you should make sure you've claimed each issue in JIRA, and create a "Code Task" in JIRA that links to each issue via the "addresses" relationship.  This helps us keep track of who is working on what, and where.

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.

...

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

See the Fedora Release Process document

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.