Explanation of bug triage (source
In a hospital, triage happens the instant a patient arrives through the emergency room doors. His vital signs are checked, his status assessed, and he gets sorted in amongst all the other patients waiting for treatment.
Bug triage is a lot like that as we assess bugs to determine whether or not they have enough information to be worked on and assign a priority to them as soon as possible. This page explains the different aspects of triaging.
There are many open and unverified bugs in the
. You can help is in the following ways:
- Adding extra information to the bug e.g. Is it still failing in the latest stable release, a script that easily reproduces the error
- Identifying duplicates
- Confirming that a bug is fixed
In order to close bugs, you have to have 'Developer' status on the issue tracker. It's not difficult to obtain and
this is an example
of many of the bugs that require triaging. Here's what you do:
- Add extra information to existing issues and/or identify issues which can be closed
- Create a list of the issues that can be closed and send it to this
IronPython mailing list (example).
After a few of these mails (with someone vetting that you're on the right track), you'll hopefully get 'Developer' status and be able to close bugs.
The source for the IronPython.net
website is located on
. In order to edit it you'll have to
, make your changes and then send a
. An area that needs specific help is the
documentation which has quite a few TODOs.
Here are a few open bugs to get you started. This page is updated every so often so check back if you want more bugs to fix or send an email to the
importing some modules (e.g.'import random') fails in IronPython Interactive window
Implement rest of _winreg module
Implement rest of _codecs module
work item 28224
work item 27901
work item 27471
work item 27174
work item 28219
work item 28207
work item 26165
Before you start working on a bug, check to see if it has been fixed or closed yet.
Failing unit tests
There are a few skipped, disabled and failed unit tests currently in IronPython. Fixing these unit tests is important as it will reduce the chances of possible regressions.
- Array tests
- 1st issue: Might be easily fixed by adding setters which throw the correct exception,
- 2nd issue: Might be implementing reduceex_ directly on partial objects or maybe the stack trace will make the issue obvious.
- test_struct: these look fairly straight forward, and will just be dealing w/ one module implementation in IronPython.
- test_repeat in test_index.py (in the CPython test repro)
- test_float_to_string in test_types.py
- Could be hard or easy but it's certainly easy to investigate - you just need to look at the string formatter code and see what it turns %g into.
- There's more string formatting failures in here as well which could be fairly easy
- test_format.py has more string formatting bugs which could be fairly straight forward
- test_xrange: this one even mentions the function which is broken
Runtime types (these may be a little more difficult):
- test_descr.py and test_collections.py both have some interesting failures around the type system and descriptors. Some of these may be easier (e.g. test_classmethods in test_descr.py) than others but might be interesting to look at for someone more
interested into the type system side of things.