6 ms·

This such a greatly written appeal for bug reports. It explains why users need to file bugs, and dives into great detail to show that bugs do get closed and the

This such a greatly written appeal for bug reports. It explains why users need to file bugs, and dives into great detail to show that bugs do get closed and the policies of closing them (crash bugs vs other types). Kudos.

viraptor 17y ago
Unfortunately filing bugs is not enough. Memcached seems to be a well managed project, which is an exception rather than a rule (they close almost as many bugs as are opened! - that's really amazing!) And that attitude makes a difference. <rant> About a year ago I got to the stage where I stopped filing bugs for projects where I don't have a direct contact with any developer, because usually it's just a waste of time for me. I've got issues opened with OO.o, ubuntu, firefox, f-spot and others that weren't looked at for years. I didn't even get a response from developers to verify most of them... OO.o is the winner with 4 issues opened and 0 closed since 2005 followed with ubuntu with 16 triaged / confirmed (but no fixes). Developers - please take example from memcached. If you let someone wait for 3 years, and then ask "so how do I reproduce it" the only answer you're likely to get is "don't know, I'm using some other app since 2005, because you can't be bothered to fix bugs"
- there 17y ago
  it's difficult to compare a project like memcache to firefox. the memcache bug list page can probably fit on a single screen, whereas firefox probably has hundreds if not thousands of open bugs due to the size of the codebase. once a list of open bugs gets too big, users won't bother searching for duplicates or can't accurately find them, and new developers won't know where to jump in, so the list just keeps getting bigger. add to that the fact that many users don't include proper information like how to reproduce the problem, test cases, backtraces, etc. and once developers actually get around to looking at those bugs, they have no interest in tracking down a user whose email will often bounce or isn't running the software anymore, just to reproduce an issue that may have been fixed by some other change months ago.
  - btilly 17y ago
    The lesson I take from that is to work hard to keep your buglist low. As an example look at OpenBSD. By my count from http://www.openbsd.org/query-pr.html http://www.openbsd.org/query-pr.html they have 208 open bugs, of which they are actively working on over a third of them. That's for a whole operating system!
    - there 17y ago
      yes, a few things have been done to get to that point. 1 - make the kernel tell the user exactly what to report in the case of a kernel panic http://www.openbsd.org/cgi-bin/cvsweb/src/sys/ddb/db_trap.c.diff?r1=1.13;r2=1.14 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/ddb/db_trap.c.... 2 - rewritten sendbug to remove useless fields and automatically add useful information for developers (dmesg output, acpi dumps, etc.) to make it easier to trace problems to specific hardware http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/sendbug/sendbug.c http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/sendbug/se... 3 - quickly respond to new bugs. if they are valid, poke a developer that will know something about it. assign the bug to someone or at least mark it as verified. if the bug report doesn't have the required info or isn't valid, respond to the user and close it right away. don't let things pile up.
  - viraptor 17y ago
    I definitely understand that there's a huge difference in size. But I wouldn't mind people closing bugs with "I don't think it's worth my time" in firefox. It would be bad, but still better than letting the report rot at the bottom of the list when the user is not even sure if the report was ever read by anyone.
    - boucher 17y ago
      Much like e-mail, if you let things fester they will get forgotten. Sometimes, I think projects need to be willing to declare bug bankruptcy and close all non top-priority bugs to start fresh.

viraptor 17y ago

Unfortunately filing bugs is not enough. Memcached seems to be a well managed project, which is an exception rather than a rule (they close almost as many bugs as are opened! - that's really amazing!) And that attitude makes a difference. <rant> About a year ago I got to the stage where I stopped filing bugs for projects where I don't have a direct contact with any developer, because usually it's just a waste of time for me. I've got issues opened with OO.o, ubuntu, firefox, f-spot and others that weren't looked at for years. I didn't even get a response from developers to verify most of them... OO.o is the winner with 4 issues opened and 0 closed since 2005 followed with ubuntu with 16 triaged / confirmed (but no fixes). Developers - please take example from memcached. If you let someone wait for 3 years, and then ask "so how do I reproduce it" the only answer you're likely to get is "don't know, I'm using some other app since 2005, because you can't be bothered to fix bugs"

there 17y ago
it's difficult to compare a project like memcache to firefox. the memcache bug list page can probably fit on a single screen, whereas firefox probably has hundreds if not thousands of open bugs due to the size of the codebase. once a list of open bugs gets too big, users won't bother searching for duplicates or can't accurately find them, and new developers won't know where to jump in, so the list just keeps getting bigger. add to that the fact that many users don't include proper information like how to reproduce the problem, test cases, backtraces, etc. and once developers actually get around to looking at those bugs, they have no interest in tracking down a user whose email will often bounce or isn't running the software anymore, just to reproduce an issue that may have been fixed by some other change months ago.
- btilly 17y ago
  The lesson I take from that is to work hard to keep your buglist low. As an example look at OpenBSD. By my count from http://www.openbsd.org/query-pr.html http://www.openbsd.org/query-pr.html they have 208 open bugs, of which they are actively working on over a third of them. That's for a whole operating system!
  - there 17y ago
    yes, a few things have been done to get to that point. 1 - make the kernel tell the user exactly what to report in the case of a kernel panic http://www.openbsd.org/cgi-bin/cvsweb/src/sys/ddb/db_trap.c.diff?r1=1.13;r2=1.14 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/ddb/db_trap.c.... 2 - rewritten sendbug to remove useless fields and automatically add useful information for developers (dmesg output, acpi dumps, etc.) to make it easier to trace problems to specific hardware http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/sendbug/sendbug.c http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/sendbug/se... 3 - quickly respond to new bugs. if they are valid, poke a developer that will know something about it. assign the bug to someone or at least mark it as verified. if the bug report doesn't have the required info or isn't valid, respond to the user and close it right away. don't let things pile up.
- viraptor 17y ago
  I definitely understand that there's a huge difference in size. But I wouldn't mind people closing bugs with "I don't think it's worth my time" in firefox. It would be bad, but still better than letting the report rot at the bottom of the list when the user is not even sure if the report was ever read by anyone.
  - boucher 17y ago
    Much like e-mail, if you let things fester they will get forgotten. Sometimes, I think projects need to be willing to declare bug bankruptcy and close all non top-priority bugs to start fresh.