Bug Statistics

Development Misc
1

I’ve been reviewing the bugs in the issues list and investigating their status. There are currently 154 open bug issues. I’ve written some Python scripts to automatically categorize and analyze the remaining issues with the bug label. With the caveat that the categorization code is simple and not completely accurate and that some issues may not be labeled correctly, the following are the top 10 areas with the most issues.

ui: 25 bugs, created=2/392/697 days, updated=0/36/544
persistence: 18 bugs, created=4/128/536 days, updated=-1/6/211
core: 18 bugs, created=39/241/441 days, updated=3/6/388
zwave: 9 bugs, created=20/211/682 days, updated=6/6/405
knx: 7 bugs, created=65/562/738 days, updated=3/6/372
modbus: 6 bugs, created=111/322/719 days, updated=6/6/41
tcp: 3 bugs, created=73/170/513 days, updated=3/6/40
rfxcom: 3 bugs, created=90/113/389 days, updated=6/44/48
heatmiser: 3 bugs, created=137/275/275 days, updated=6/37/148
dropbox: 3 bugs, created=4/604/738 days, updated=1/36/365

The ui category includes the Classic UI, GreenT and the Designer and the median issue age is over a year old. The persistence category include all the persistence providers. The “created” and “updated” numbers are the min/median/max number of days since the issue was created or updated.

The following shows a histogram of the ages (in days) since creation and the time since the last update. The updated times are misleading because I’ve updated many issues recently with labels or comments. Many of the issues have not been updated for a very long time.

The question I have is how do we continue to make progress reducing the size of the bug issue backlog.

Some of these bugs will be resolved as we work through the PR backlog. I’ve started tagging issues with “pr-submitted” if there is a bug fix submission. If anybody else knows of bug issues with PRs, please add the tag. After we make more progress on the tagging, I can rerun the analyses for the remaining bugs.

I’m wondering if the ui category has so many unresolved bugs because that code will become obsolete as OH2 approaches being ready for general use. If so, I think we should consider closing/resolving some of those issues as “wontfix”.

4 Likes
2

Thanks for pointing to this post, I have to admit that I didn’t notice it ever before :frowning:

I agree that all what you say. I think you are right that many things are obsolete and are unlikely to be fixed, because development meanwhile continues on openHAB 2. So all stuff that is related to the Designer, GreenT, the Classic UI can imho be immediately closed.
For the bugs that are related to a specific binding, I think the most effective way might be trying to pester the according developers/contributors of this binding, whether they could look into it. If a binding is fully abandoned and has serious bugs or is not functioning at all, we can also consider to remove it completely from the repo (together with its issues).

3

That makes sense to me. I’ll tweak my github scripts to identify issues in the categories you’ve mentioned and will adjust the status on those over the next few days. What about issues related to OH1 core bindings/bundles? The policy is to only change those if absolutely necessary, right?

It seems that any bug report older than a year or so may be a candidate for marking as" not reproducible" or “won’t fix”. I’ll take another look at those older bug reports, but I’ll post a message before I start changing the status on them (to ensure team consensus).

We should also remember that some percentage of the open issues are feature requests and not bug reports. In other words, the issue count doesn’t directly indicate problems in the code base.

4

The core bundles are actually removed from the repo, so issues about them are not applicable for 1.9.0.
So yes, they should only remain open if they qualify for a critical fix that should go into 1.8.3.

We should also remember that some percentage of the open issues are feature requests

We already changed the strategy in the past to ask people rather to discuss feature requests in the forum than adding an issue - only once someone says that he is working on a feature, an issue should be created to make this visible.