![\"\"](\"http:\/\/dlang.org\/blog\/wp-content\/uploads\/2018\/02\/bug.jpg\")
Every major release of DMD comes with a list of closed issues from Bugzilla<\/a>. For example, looking at the changelog for DMD 2.078.0<\/a> shows the following counts for closed regressions, bugs, and enhancements: 51 for the compiler, 37 for the standard library, 6 for the runtime, 17 for the website, and 1 for the linker. That\u2019s 112 total issues, the majority related to the compiler. The total number of closed issues fluctuates between releases, but the compiler and standard library normally get the lion\u2019s share.<\/p>\nThis isn\u2019t news to anyone who regularly follows DMD releases. But spend enough time on the forums and you\u2019ll eventually see someone under the impression that bugs aren\u2019t getting fixed. They cite the number of open issues in the database, or the age of some of the open issues, or the fact that they can\u2019t find any formal process for fixing bugs. In reaction, it\u2019s easy to point to the changelogs, or cite the number of closed issues in the database, or bring up the number of open issues in other language compilers. And, of course, to explain once again that this is a volunteer community where people work on the things that matter to them, and organizing groups to complete specific tasks is like herding cats.<\/p>\n
That\u2019s all quite reasonable, but really isn\u2019t going to matter to someone who found the motivation to check D out, but is still looking for the motivation to stay. For me personally, I really don\u2019t care how many issues are in the database, or the age of the oldest. All I care about is that it works for me. But I\u2019m already invested in D. I don\u2019t need to be motivated to stick around. And while I wouldn\u2019t use a bug database as criteria to judge a new language, I can see that others do. It\u2019s akin to looking at a stable repository on GitHub and dismissing it as abandoned because of its lack of recent activity. If you don\u2019t see the whole picture, you can\u2019t make an informed judgement.<\/p>\n
If perception were the only issue, then it would simply be a matter of web design and PR. However, there have been, and are, people invested in D who have become frustrated because issues they reported, or that directly affect them, have languished in Bugzilla for months or even years. This can\u2019t simply be dismissed as not seeing the whole picture. This is a matter of manpower and process. A number of issues are still open because there isn’t a simple fix, or perhaps because no one has taken an interest. The set of people who can solve complex issues is small. The set of people willing to work on issues that aren’t interesting to them is smaller. But again, how do you get a disparate group of volunteers of varying skill levels to devote their free time to fixing other peoples\u2019 problems?<\/p>\n
This is something the D community has struggled with as it has grown. There are no easy, comprehensive solutions without a full-time team of dedicated personnel, something we simply don\u2019t have. However, it\u2019s possible that there are opportunities to take baby steps and chip away at some of these issues without the complications inherent in herding cats.<\/p>\n
The #dbugfix campaign<\/h3>\n
To recap, there are two primary complaints about the D bug-fixing process (such as it is):<\/p>\n
- \n
- Too many (old) bugs in the database<\/li>\n
- Bugs you care about aren\u2019t getting fixed<\/li>\n<\/ul>\n
In an effort to alleviate these problems, one baby step to chip away at it, I\u2019m announcing the #dbugfix<\/strong> campaign.<\/p>\n
It works like this. If there is an issue in D\u2019s Bugzilla<\/a> that you want to see fixed, whatever the reason (maybe it\u2019s blocking you, or it\u2019s annoying you, or it\u2019s an enhancement you want, or you think it\u2019s too old \u2013 it doesn\u2019t matter), then either tweet out the issue number with #dbugfix<\/strong> in the tweet, or create a topic in the general forum<\/a> with the issue number and #dbugfix<\/strong> in the subject line. I\u2019ll monitor both Twitter and the forums and keep a running tally of issue numbers.<\/p>\n
A week before a major version of DMD is released (starting with 2.080.0, which is slated for May 1), I\u2019ll look at the tally and find the top five issues. I\u2019ve already gotten people to commit to fixing at least<\/em> two of the top five. That doesn\u2019t mean only<\/em> two. It could well be more. It depends on the complexity of the issues and how many other volunteers we can scrounge up. Hopefully, the two (or more) fixed bugs will be ready to be merged in the subsequent major release.<\/p>\n
In the blog post announcing each major release, I\u2019ll report on which bugs in the current release were fixed as a result of the campaign and announce the two selected for the subsequent release. If any of the top five from the previous release were not fixed, I\u2019ll call for volunteers to help so that they can be squashed as soon as possible.<\/p>\n
Yes, I know. We enabled voting on Bugzilla issues and that didn\u2019t change anything. That\u2019s because there was no real commitment to fixing any of the highest-voted issues. The votes simply served a guideline for the people browsing the database, looking for issues to fix. For this campaign, there really are people committed<\/em> to fixing at least two of the issues that float to the top for every major release.<\/p>\n
But two is not a lot! No, it isn\u2019t. But it also isn\u2019t zero. As I mentioned at the top of this post, dozens of issues are already fixed with each major DMD release. The problem (for those who see it as such) is that there\u2019s currently next to zero community involvement in deciding which issues get fixed. This campaign gives the community more input into the selection process and it provides public updates on the status of that process. It is my hope that, in addition to changing perception and chipping away at the bug count, it encourages more people to help fix bugs.<\/p>\n