We always welcome new testers.

But if you're running an alpha client, the best place to report bugs is to the alpha email list. You will need to subscribe. Note that at times, the volume of email you receive may be high, especially as a new version enters testing.

Jord and I (along with numerous others on these forums) are subscribed to the list and we can report bugs, but only you know the details of your set up.

Also, please read over the testing instructions and the test matrix.

You should also set up an account on Trac to log bugs.

You should also set up an account on Trac to log bugs.

Registering accounts on Trac goes through David Anderson, to cut back on spam accounts on there.

David Anderson, 9 November 2009 wrote:

I re-enabled users to add and modify tickets on the BOINC trac system.

I removed the ability to create new accounts (to prevent spam).
If anyone wants an account, email me.

-- David

Email David Anderson (recaptcha protected email address).

You found some anomaly or suspected bug in the latest BOINC Development version and you want to report it to the BOINC Alpha email list, how are you going to tackle that correctly without annoying the developers?

Keep an eye out on earlier messages on the alpha email list. It is possible that your problem was reported before.
To do so, check through its archives after you registered your account and before you send your bug in. These archives cannot be looked into without an activated account.

When you're reasonably sure you're the first one seeing these strange things, make preparations for a good log. The BOINC software is capable of lots of debug logging, as long as you enable this. The main ones for logging problems with the client are:

<cpu_sched_debug>: problems involving the choice of applications to run.
<work_fetch_debug>: problems involving work fetch (which projects are asked for work, and how much).
<rr_simulation>: problems involving jobs being run in high-priority mode.
<sched_op_debug>: problems involving scheduler operations and other low level information.
<task_debug>: problems showing low-level details of process start/end (status codes, PIDs etc.), and when applications checkpoint.

Enabling these flags will run your cache full quite quickly, which is why you probably want to run with a temporarily increased log capacity. So in such a case, you run with a cc_config.xml file from your BOINC Data directory, with the following entries:

<cc_config>
    <log_flags>
        <task_debug>1</task_debug>
        <cpu_sched>1</cpu_sched>
        <sched_op_debug>1</sched_op_debug>
        <cpu_sched_debug>1</cpu_sched_debug>
        <work_fetch_debug>1</work_fetch_debug>
        <rr_simulation>1</rr_simulation>
    </log_flags>
    <options>
        <max_stdout_file_size>181192000</max_stdout_file_size>
    </options>
</cc_config>

The <max_stdout_file_size> will increase the stdoutdae.txt file to ~180 megabytes. Enough for you to capture at least 20 hours worth of data in.
Capture at least an hour, preferably slightly more. When sending a log in to the alpha email list, place part of your log in the post, zip or otherwise compress the rest and wait for a developer (David Anderson, Rom Walton, Charlie Fenton, John MacLeod) to react and send your full compressed log to this person. Make sure that when you send the log, that you do not use the "Answer all" option. Just answer the developer, do not include the list or other people. You can continue posting to the list afterwards.


References:
Hard Bugs for more information on reporting hard bugs.
Alpha Instructions for more information about being an alpha tester.
Client Configuration Flags for more information on which flag does what?

---