And again, a day or two too late! I’ll just pretend that good things are worth waiting for.
Last week has again been full of bug fixing. Since much of the easy bugs has been handled, it is going to show in our closing speed as reports need more and more time to investigate and verify. That doesn’t mean we stop working of course, on the contrary. Last week I closed over 40 reports. This includes the reports that we mark as todo on our wiki todo list. A lot of time went also in investigating new (and old) reports and getting more information for those.
People have been asking me how we handle bug reports. For Blender 2.5x series we use the Blender 2.5 Bug Tracker (which is still behind log in) with bugs set to data type Blender 2.5 Bug Tracker.
In our tracker we have the following states for Resolution: None, New, Investigate, Ready (rare, prestage for Fixed), Approved, Rejected, Postponed (unused), Fixed, Duplicate and Todo.
When a new report is submitted the report is None, sometimes the user sets to New, either way is OK. The next step is for a dedicated developer to do a first assessment of the report. The idea of the triaging is that the developer tries to determine if it’s a valid report and if so, assign it to a developer who can handle the bug (code owner, module owner). The bug will be assigned and set to New, or if the triaging developer is certain, Approved. If a report is not valid, the report is marked Rejected and State is set to Closed. An invalid report is often:
- misunderstanding of how a feature works
- a user not aware of some feature
- something that didn’t work like a user expected, but was designed or implemented in that way
Either the triaging or assigned developer can set Resolution to Investigate, although this is not often used by all developers. I like to put it on Investigate to signal the reporter and interested parties that the issue is being looked at. When a bug is fixed the assignee sets Resolution to Fixed and State to Closed. This we do mostly on basis of testing by developer, who might or might not have asked other developers to test. This depends on the complexity of the issue. Only if the reporter notices that an issue hasn’t been fixed properly is a Fixed and Closed report reopened.
If similar reports have been reported before it is marked as Duplicated and set their State to Closed. We try to put in comments of both the duplicate and original bug links to the other report, so all can be verified when a fix is found.
To help us manage the influx of bugs we’ve decided to keep in the bug tracker only reports that are actual bugs to our standards. A bug is something that is intended (code and design) to work, but doesn’t.
Reports can be marked also as Todo and moved to the todo wiki. In that case reports are closed too. Reports eligable for move are often related to features that haven’t been fully implemented (or at all). Also reports of recurring issues that we have trouble finding good solutions for in a short timespan can be moved to this todo page. An example is several OpenGL problems that can happen on some cards, but also some larger tasks that can take some time and need someone to sit down and actually do it. The todo list is for both old developers and for those who want to start working on Blender code. The bug tracker is a good place, of course, but our todo page will contain sections that can have links to the bug tracker, and are thus easier to oversee for developers. Right now the todo list is in many places just bunch of bullet lists, but I intend to write out more details for as many sections as possible in the coming time as part of my role for Development Support, along with coder documentation on what to do, how, where, etc.
The rules are not enforced, but it would be benificial if both users and developers followed the rules as much as possible. It’ll help me and others in handling the bugs and quickly respond to changes and new ones.
I hope this short overview helps users and developers in understanding how our process works.
Enough of the boring stuff, let’s have some diagrams and numbers of the current development progress:
2010.09.12: theeth closed 1 issues
2010.09.12: jesterking closed 3 issues
----- total 4 bugs closed. New bugs for this day: 8
2010.09.13: aligorith closed 2 issues
2010.09.13: campbellbarton closed 13 issues
2010.09.13: jhk closed 7 issues
2010.09.13: jesterking closed 12 issues
----- total 34 bugs closed. New bugs for this day: 12
2010.09.14: jesterking closed 1 issues
2010.09.14: jhk closed 3 issues
2010.09.14: campbellbarton closed 1 issues
2010.09.14: nazgul closed 1 issues
----- total 6 bugs closed. New bugs for this day: 15
2010.09.15: dingto closed 2 issues
2010.09.15: aligorith closed 1 issues
2010.09.15: jhk closed 1 issues
2010.09.15: jesterking closed 2 issues
2010.09.15: campbellbarton closed 10 issues
2010.09.15: blendix closed 13 issues
----- total 29 bugs closed. New bugs for this day: 17
2010.09.16: aligorith closed 1 issues
2010.09.16: jesterking closed 10 issues
2010.09.16: nazgul closed 1 issues
2010.09.16: broken closed 1 issues
2010.09.16: campbellbarton closed 1 issues
2010.09.16: blendix closed 10 issues
----- total 24 bugs closed. New bugs for this day: 22
2010.09.17: blendix closed 4 issues
2010.09.17: jhk closed 5 issues
2010.09.17: campbellbarton closed 6 issues
2010.09.17: jesterking closed 6 issues
2010.09.17: nazgul closed 1 issues
----- total 22 bugs closed. New bugs for this day: 12
2010.09.18: campbellbarton closed 3 issues
2010.09.18: jhk closed 1 issues
2010.09.18: damien78 closed 1 issues
2010.09.18: jesterking closed 6 issues
2010.09.18: blendix closed 5 issues
----- total 16 bugs closed. New bugs for this day: 6
2010.09.19: blendix closed 4 issues
2010.09.19: jesterking closed 2 issues
2010.09.19: campbellbarton closed 1 issues
----- total 7 bugs closed. New bugs for this day: 3
I want to thank all of the involved developers, especially Brecht, who clearly has been on a hot streak two days in a row.