Join GitHub today
XMMS2 Development Process
This is an overview of the XMMS2 development process - it covers the process to go through when modifying code that ends up in the main code tree (xmms2-devel), as well as outlining other trees.
- Get an idea for a feature/plugin, or find a bug somewhere. Optionally discuss it with other people in the XMMS2 community. Optionally start one or more wiki pages outlining the idea and link them to Developer Ideas
File a bug or feature report. You will need to register on the Mantis bug tracker if you don't already have an account.
- If you've already got code to submit (e.g. a new plugin), you'll still need to file a report - it's how we track changes to the codebase. Skip step 2.
If you're not lazy and you think you're up to it, work on the bug or feature or plugin and submit your file(s) via Mantis.
- If your code is too complex to submit via Mantis (e.g. too many files), you might want to contact us via e-mail or IRC to discuss a more convenient way of submitting your code.
- You can seek feedback from the XMMS2 community by offering code and patches for review while working on the problem, before submission.
If your submission is deemed of good enough quality (i.e. works, doesn't introduce any obvious bugs, memleaks, and so on), it will be merged into one of the code trees and eventually end up in xmms2-devel.
The bug/feature report will be closed on mantis with the matching git commit ID.
You'll probably end up in the AUTHORS file, if you're not in there already.
In summary: The Mantis issue tracker is a vital component of, and primary entry point to the XMMS2 development process. Use it well.
- When resolving an issue, a git commit ID is required, which allows us to easily track down which commit reportedly fixed a certain issue.
- The gitweb interface parses the various commit tags and provides hyperlinks back to the issue tracker so that anyone can figure out exactly what bug is fixed, or what feature is implemented, by a specific commit.
The development process has largely evolved thanks to the de-facto standardised commit tags and subsequent service integration.
Examples of using commit tags
Changing the mime-handling to make decoders register magic.
- Is a feature request in mantis, add FEATURE(123)
- would change the decoder api and force plugins to do the registering, old plugins wont work, add PLUGINMAJOR
FEATURE(123),PLUGINMAJOR: New shiny mimehandling
- Feature request in mantis - FEATURE(321)
- Adds new features to clientlib. Existing features are not affected, old clients will continue to work, but new clients using the new feature will not work with old clientlib. CLIENTMINOR
FEATURE(321),CLIENTMINOR: Add pcm-visdata
There is no firm release calendar or roadmap for XMMS2. The release cycle is typified as follows:
- File a new feature request titled to the next release name as per Versioning.
- Identify bugs to fix and features to implement as reported on the issue tracker and add them as child issues of the release issue.
- Once all (or most of) the children issues of the release issue have been resolved, prepare a release, as per Release Checklist
- Some issues may be re-categorised as low-priority issues, dropped from the current release cycle and moved forward to the next release cycle. This can happen especially if there have been a number of important updates to the codebase and no releases have been made for a fairly long time.
These are the trees found at http://git.xmms2.org
- Anders' tree - where lots of code ninja happens.
- The main development tree, where all approved changes end up.
- Sham's tree - where minor bug fixes and documentation fixes are occasionally committed.
- Jens' tree - where changes relating to Debian packaging are made.
- Daniel's tree.
- The stable tree, where code from the xmms2-devel tree ends up prior to a release.
- Tilman's tree - where some code ninja happens.
- Tobias's tree - where even more code ninja happens.