Hacker News new | comments | show | ask | jobs | submit login
Memcached - Report Card for an Open Source Project (dustin.github.com)
84 points by r11t on Oct 22, 2009 | hide | past | web | favorite | 14 comments



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.


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"


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.


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 they have 208 open bugs, of which they are actively working on over a third of them. That's for a whole operating system!


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....

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/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.


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.


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.


Since users/fans of memcached will be reading this I wanted to ask a quick question: I wrote a debug version of memcached in Python that has a couple of "x" commands in it - xdump which dumps all the data in the hash using the same return format as get and xtrace which keeps the connection open and dumps the incoming commands, values and results as they come in.

I was thinking of writing an Adobe Air app that uses xdump and xtrace to let you view/edit usage of memcached. A friend has a project on github that lets you do this in 1 app on a mac but the Air app would be cross platform.

Thoughts on releasing this as an open source project?

btw, the Mac app is at http://github.com/gerardg/mcinsight - its a fork of another project.


> Thoughts on releasing this as an open source project?

The only reason I'd say you shouldn't release something as an open source project is if you strongly feel that someone is going to hand you a sufficient amount of cash to keep it proprietary (and even then, it's pretty easy to convince them that there's potentially more value in your project as open source).

I have regretted not pushing projects forward as open source in the past. I have never regretting making something open source.


It's refreshing to see such a level of humility from an open source project!


I hate to immediately divert the discussion off topic, but does anyone know what tool can be used to make attractive graphs like the ones in this article?



OmniGraphSketcher is a great little app. It approaches the graphing problem from the opposite direction that traditional graphings apps take.


This is a great report. I intent to try and start doing something similar to this on our projects in the future. Thanks!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: