At least for now, /scdev/ is where you'll want to report bugs. Start a new thread, hopefully with enough information to track down and reproduce the problem. If you can't make it happen again, I have little or no chance of finding and fixing it.

Using a Distributor

The distro-packages tend to lag significantly behind live development. You should probably try one of the builds from the main page if you have a problem, at the very least to make sure yor bug hasn't already been fixed.

If your distro's package is more than a few months out of date, please ask them to update it! Often, tons of changes can happen in that amount of time, and holding onto very old versions is a great way to make other people put up with bugs that have long since been fixed.

Tracking down problems yourself

For this, you will almost always have to build from source. The builds on the website are optimized and have debugging symbols stripped out, so they are probably not very useful for finding bugs.

  1. Configure with --enable-debug. Try using --enable-ludicrous-mode as well – especially if you're on a system that isn't officially supported, this might hint at bugs that have been overlooked.
  2. Run gdb schismtracker, and type run at the (gdb) prompt. Continue until it crashes.
  3. After the program stops, type bt to see what broke. If it looks like garbage – lots of numbers and question marks, and nothing else – try thread apply all bt to see what might have been happening elsewhere.
  4. Copy all the output to a text file, and attach that to a post on /scdev/. Give the usual details (OS, compiler version, CPU type, blood type, height, etc.) as well as what you did to cause the crash.

If you want to go the extra step, try to narrow down what version introduced the problem. This is made somewhat easy in most cases with hg bisect, assuming you used Mercurial to fetch the source.

  1. Find a build: hg log | less and page down a bit. You can test changesets pretty much arbitrarily, but pick one that's maybe a few months old.
  2. Copy the hexadecimal number for the changeset you picked. (b286c28d65b0 for example)
  3. Update to that changeset: hg update b286c28d65b0 (for example)
  4. Run make, and hopefully it will build properly. You might have to reconfigure if make dies (e.g. `./configure --enable-debug && make) as autoconf gets rather confused if you update across changesets that renamed or removed files.
  5. Try to reproduce the bug.
  6. Update to the next changeset.
    • If it died: hg bisect -b ("bad")
    • If it worked fine: hg bisect -g ("good")
  7. Repeat steps 4-6 until Mercurial stops and tells you which changeset introduced the problem.
  8. Copy the output and post it on /scdev/. (If you're really ambitious, you might want to look through that changeset's diff for the cause.)
  9. When you're done, hg bisect -r; hg update default to get back to normal.

Making feature requests

You can post suggestions to /sc/ and see what other users think. Try to demonstrate why it would be useful, in terms of other people – not-very-convincing clichés like "Schism Tracker is almost perfect, but..." or "I would use [feature] every day" aren't thoroughly helpful. If every single "wouldn't it be cool if..." idea was implemented, Schism Tracker would become completely useless and bloated.

Some other points that you might want to address: