Testing

One of the most helpful things both regular users and developers can do is to test others' code. The easiest way to do this is to run the development version of Quod Libet. Development versions are kept stable, and the developers generally run the latest code to play their own music, so this is a safe and helpful way to contribute.

Please keep in mind that Quod Libet is not forward compatible, meaning that if you use a newer version, reverting to an older version could lead to errors and data loss. So always backup your config files if you plan to downgrade at a later point.

Development builds

Ubuntu

If you use Ubuntu you can add the Quod Libet unstable PPA to test the current development code.

$ sudo apt-add-repository ppa:lazka/dumpingplace
$ sudo apt-get update
$ sudo apt-get install quodlibet quodlibet-plugins
$ sudo apt-get upgrade

If you prefer the current stable release, but don't want to update to the newest Ubuntu release you can add the stable PPA: ppa:lazka/ppa

Debian

deb http://www.student.tugraz.at/christoph.reiter/debian/ quodlibet-unstable/

Windows

You can find recent development installers in the Downloads section.

Getting the latest code

See Development#Getting_started on how to install/run Quod Libet.

Filing bug reports

The more information provided in a bug report, the more likely a bug can be reproduced on another system. Good examples of details include:

• OS, distribution, and version
• Versions of Python, Quod Libet, Mutagen, GTK, PyGTK, GStreamer, libXine
• A list of all enabled plugins
• The current browser
• Debug log information (dump files)

For more tips see How to Report Bugs Effectively.

Misbehaving plugins are a common source of bugs. Try reproducing the bug with all plugins disabled; if the bug is gone, enable them one by one until you find the combination of plugins that triggers the bug.

If the bug you have found does not raise an exception, the debug window won't appear and the dump won't be generated. In this case, run quodlibet from the command line using the command $ QUODLIBET_DEBUG=1 quodlibet, and use 'Cause an error' from the Help menu to produce the dump.

Some problems are fixed in the development branch which aren't yet fixed in the current release. If you can, try to reproduce your bug against a recent checkout before filing.

Please do not create an item in the issue tracker which contains reports of multiple unrelated issues. Even if you are reporting several very minor bugs, each one deserves its own issue. This allows each issue to receive independent discussion and analysis, and to be closed separately.

• Add a new bug
• Show current bugs

Filing enhancement requests

The most important component of an enhancement is the why. State what it is Quod Libet doesn't do for you, and give as much information about why you think adding a feature which accomplished this would be a good thing. If you have an idea as to how a feature might be implemented, suggestions are welcome, but be sure to explain why you want a feature before explaining how you envision it being implemented. Not only does this make your feature more likely to be supported, it allows others to enhance, generalize, and refine your ideas.

As with bugs, please refrain from submitting multiple feature requests in the same issue. If you have related ideas, file them separately and mention the issue numbers of previous ideas.

Translation

Help us translate Quod Libet into other languages. You don't need to know how to program in Python to do it. Read our vocabulary and style guidelines, and notes on access keys and accelerators.

Submitting patches

Patches are always welcome, and should be attached to the issue tracker. We review every issue and tag the ones which include patches, so there's no need to add "PATCH" to the issue summary.

We try to keep Quod Libet's code in pretty good shape; when submitting a patch, it's much easier to get it included quickly if you run through this checklist of common-sense code quality items. Make sure your patch:

• is PEP 8 compliant. Yes, this means an 80-character line length.
• passes existing tests, and includes new ones if at all possible.
• is commented.
• adds your name to the copyright header of every file you touch. This helps you get credit and helps us keep track of authorship.

See Development on how to get started.

Editing the wiki

If you spot outdated text or think a feature is not explained well enough, feel free to change it. You can get wiki editing rights by becoming a member.

Becoming a member

Google Code doesn't let you grant privileges to non-members, meaning only members have wiki, bug triage, and commit privileges. If you want to edit the wiki or help manage bugs, just ask; QL has a small development team and we'll take all the help we can get. Commit privileges aren't much harder to obtain: submit a few decent patches and then send an email to a project owner.