5 ms·

Memcached - Report Card for an Open Source Project

84 points by r11t 17y ago

chwahoo 17y ago
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?
- dlsspy 17y ago
  I used this thing: http://www.omnigroup.com/applications/omnigraphsketcher/ http://www.omnigroup.com/applications/omnigraphsketcher/
  - boucher 17y ago
    OmniGraphSketcher is a great little app. It approaches the graphing problem from the opposite direction that traditional graphings apps take.
pierrefar 17y ago
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
dugmartin 17y ago
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 http://github.com/gerardg/mcinsight - its a fork of another project.
- dlsspy 17y ago
  > 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.
p0ppe 17y ago
It's refreshing to see such a level of humility from an open source project!
boucher 17y ago
This is a great report. I intent to try and start doing something similar to this on our projects in the future. Thanks!

84 points by r11t 17y ago

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?

dlsspy 17y ago
I used this thing: http://www.omnigroup.com/applications/omnigraphsketcher/ http://www.omnigroup.com/applications/omnigraphsketcher/
- boucher 17y ago
  OmniGraphSketcher is a great little app. It approaches the graphing problem from the opposite direction that traditional graphings apps take.

pierrefar 17y ago

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

dugmartin 17y ago

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 http://github.com/gerardg/mcinsight - its a fork of another project.

dlsspy 17y ago
> 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.

p0ppe 17y ago

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

boucher 17y ago

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