Development: Bug Days
Occasionally, wxWidgets organizes "Bug Days" for the purpose of tracking down, fixing, and closing bugs reported in the bug tracker. Usually bug days are organized before a new stable release is scheduled, but wxWidgets is often overloaded with open bugs (that often haven't been looked at for weeks at a time), and is always looking for help.
Scheduled Bug Days
| Date | Goals |
| January 21, 2006 | Preparation for the 2.6.3 release. |
How to Help
Bug Days are held in the #wx-bugs IRC channel on the FreeNode.net IRC network. FreeNode server information can be found here.
You should use at least wxWidgets 2.8.0. Ideally, you should use WX_2_8_BRANCH (not HEAD) in CVS, but this isn't always required, and during Bug Days, you can also check with others using different versions. Instructions on checking out code from CVS can be found here. The highlights are:
cvs -d :pserver:[email protected]:/pack/cvsroots/wxwidgets login cvs -d :pserver:[email protected]:/pack/cvsroots/wxwidgets checkout -r WX_2_8_BRANCH wxWidgets
If asked for a password, use "anoncvs".
The process goes roughly like this:
- Pick any bug from the bug tracker that you feel you can handle (avoid platform specific bugs for platforms you don't have access to).
- Confirm that it really is a bug. If you can't replicate the bug using the version of wxWidgets it was reported to exist in, tell one of the admins in #wx-bugs so someone with the access can close it.
- Test if the bug still exists with the latest version of wxWidgets on the appropriate platform (if it isn't a common bug). If it does, you can attach a comment confirming it's current existence.
- Ensure there is enough good information about the bug on the report in the tracker. Try to provide more about it's behavior and what it affects if there isn't.
- Ensure the category, group, priority, and bug title settings are as accurate as possible. Ask in #wx-bugs to change those settings if necessary.
- Send a message to the #wx-bugs channel with the bug number that you added information to, so we can collect a listing of bugs that now have more information (so the wxWidgets developers can take a second look if necessary). Please prepend the number with "#" so they can easily be found in IRC logs (e.g "#123456").
- If you'd like to fix the bug yourself, let the channel know. This step is not a necessity at all, the previous steps are helpful on their own. Check out the bug using the instructions below to ensure that you aren't working on a bug someone else is working on.
Checking Out Bugs to Work On
wxOracle is an IRC bot (a program running as an IRC user). It has a plugin which allows us to keep track of which bugs are being looked at or have been brought to conclusions.
- Whenever you start working on a bug that will take more than a very small amount of time, check it out so that others know. If you're working on bug number 42, type the following in the channel: "@checkout 42" (without quotes)
- If you bring the bug to a reasonable conclusion (verify, close, etc.), type the following in the channel: "@finish 42"
- If you need to leave without completing your examination of the bug, release the bug so others can look at it: "@release 42"
Creating Patches
If you want to create a patch, please read the patch submission guidelines.