Contributions to distro-tracker are greatly appreciated! You can contribute in many ways, be it writing documentation and blog posts, or fixing bugs and implementing new features.

Join the community

The recommended way to send feedback is to write to the Debian Quality Assurance mailing list <>. You can also reach us using IRC on the #debian-qa channel at

You can also report bugs against the pseudo-package, to do so please follow the usual instructions.

When you report a bug, ensure you include detailed steps to reproduce it and any details that might be helpful in troubleshooting.

If you are proposing a feature, please explain in detail how it would work, and keep the scope as narrow as possible, to make it easier to implement.

If you do not know where to start, we have a list of tasks suitable for newcomers, mentors will review your changes with special care when you try to tackle those.

Please remember this is a volunteer-driven project, and that contributions are welcome.


Ready to contribute? Here’s how to set up distro-tracker for local development:

Usual workflow

  1. Clone distro-tracker locally:

    $ git clone git://

    Note that you can also browse the sources at

  2. Follow the steps in the chapter Setting up Distro Tracker.

  3. Start a local test server:

    $ ./ runserver
    Starting development server at
    Quit the server with CONTROL-C.

    Visit the URL returned to have access to the test website.

  4. Configure the package repositories as explained in Setting up the package repositories. With your test server, the URL of the admin web interface is

  5. Switch to a new branch:

    $ git checkout -b name-of-your-bugfix-or-feature
  6. Develop your new feature, ideally following the rules of Test Driven Development.

  7. When you’re done, check that all tests are succeeding in all supported platforms:

    $ tox

    This basically runs “./ test” with multiple versions of Django and Python.

  8. Push your changes on a public repository or send them by email to the Debian Quality Assurance team:

    $ git format-patch -o . origin/master
    $ mutt -a *.patch

Test Driven Development

Have a look at Test-Driven Web Development with Python if you don’t know yet about this development methodology.

The suggested workflow looks like this:

  1. Add a functional test that covers the new feature from the point of view of the user. This test will fail since the feature doesn’t exist yet.

  2. Think about what’s the next step to let the functional test go further (i.e. fail later).

  3. Write a failing unit test for the new code that you want to write.

  4. Write the minimal code to make your unit test pass. You will typically run this very often:

    $ ./ test path-to-the-testing-folder
  5. Refactor (if needed). You might have introduced some duplication in your code or in your tests. Clean that up now before it’s too late.

  6. Commit (optional). Commit together the (working) unit tests and the new code.

  7. If you made progress from the functional tests point of view, go back to point 2, otherwise go back to point 3. If the functional test passes, continue.

  8. Commit. The functional tests are committed at this point to ensure that they are committed in a working state:

    $ git add .
    $ git commit

When you don’t develop a new feature, your workflow is restricted to steps 3 to 6.


  1. In regard to coding style, we observe PEP8 with a few exceptions.
  2. Functions are documented using doctrings with Sphinx markup.

Write access to the git repository

Debian developers in the “qa” group have write access to the repository and should use the following command to checkout a git repository where they can push changes:

$ git clone ssh://<yourdebianlogin>

Anyone with commit access can use topic branches in the “people/debianlogin/” hierarchy.