How not to handle open source feedback | Hacker News Reader

How not to handle open source feedback

jacquesmattheij.com

130 pointsColinWright35 comments

I can understand why some projects close bugs due to inactivity, but I was a little surprised to see that it was closed after only a month of idling.

Asking for a code sample test case in this instance is inappropriate, and IMHO is a lazy shirk of one's responsibilities. Sure, if I can't reproduce the bug I'll ask for a test case, but in this situation it was not called for. That's certainly not how I'd treat a user who cared enough to submit a bug in one of my programs.

I've had a bunch of my valid bug reports closed by Ubuntu. I've switched to Debian, and every one of them is being closed unless I go and reproduce the issue again in later versions of Ubuntu.

Some of them are general issues that won't have been fixed in later versions.

jwz wrote on this:

http://www.jwz.org/doc/cadt.html

"This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. "

What's most annoying is the combination of this issue and the one the author writes about: the ticket sits around for a year and then gets closed a year later for some silly reason (like lack of a test program).

I'm willing to accept that a rewrite might have fixed my issue and am willing to accept a close resolution until I retest and reopen. In this case it's, "nope, I don't believe you and you're up shit-creek until you can really prove it to me."

And your bug reports just sit there, with people popping in every few months saying they have the same problem and asking for help... but nothing ever comes of it.

I'm pretty sure every OS follows this practice, here's my personal example from Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=219715

Not my experience with Apple: I've had years-old bug reports where Apple suddenly emailed me and asked me to confirm that the bug was fixed in the latest developer preview (for an major OS version later).

Same experience here, I have 2 year old bugs fixed 2 major version later.

Unfortunately the official bug report system is opaque though.

Unfortunately the other common case for Apple is that your bug just gets marked as a duplicate, and since you only have visibility to the bugs you opened, you lose all tracking.

Filing a bug for Apple is worth the effort even if they mark it as duplicate. Duplicate reports count as "votes", the more people file the same bug the higher priority it enjoys. Apple employees mention this regularly on the Apple Developer Forums and encourage everyone to file bugs.

To be fair, testing a hardware-specific bug is a bit more complex.

In case it wasn't clear from the parent, Debian doesn't do this (at least not automatically).

I've worked on projects in the past where emphasis in placed on closing bugs, not fixing them, so this is not a surprise to me.

Sadly bug fixing in corporations is all about closing tickets.

"If you're maintaining an open source product that is meant for mainstream distribution then please do not do this, fixing bugs is not about closing tickets, it is about improving a product."

MySql is an open source project, but Oracle is not an open source organization, it's the biggest of BigCorps, with performance reviews, raises, 360s and for all I know 720s. I'm sure that bugs closed is someone's performance metric, and as we know, that which gets measured gets done.

Another example of poor bug handling (although FB is definitely not open): http://bugs.developers.facebook.net/show_bug.cgi?id=16580

This bug was wrongly closed, but when a bug is closed in their system, you cannot re-open it.

Ah, the game of hot potato. The reporter ended with it. The person asking for a test case wins.

I never ask for code to prove a bug unless I can't replicate it myself. (On the other hand, if I submit a bug, I almost always provide code before being asked.)

In this case, though... It seems only 1 person has experienced this, and didn't care enough to even reply back. Closing it due to inactivity doesn't seem to be wrong, to me.

There was no indication that any info was even sent to the user, for all he knows all was fine (and still is) just unresolved. He did his job and reported the bug in detail, oracle needs to do their job and reach out to him. Can it be reproduced? More info needed? Etc. You don't ask for test cases unless its really problematic or the dev can't figure out whats wrong in your opinion.

Most bug-trackers automatically send notices if the user has put in valid contact info. If they didn't, or opted out of the notices, then they'll see the message when they check it for updates.

If they never check it again, time is definitely better spent somewhere else.

On the other hand, the problem is pretty obvious. Not like it needs code, either the internal symbols are exported, or they are not.

And they should generally not be exported imho.

If you have a little project and it's getting one or two bug reports a week, it's fine to say that you'll create your own test cases. It's completely different for a large open-source project, where many of the reports are from users/developers who are confused and looking for technical support. With a dozen reports a day and an average of 10 minutes to create a test case, analyze, and reply, we're looking at two hours of time!

I totally agree about the "1 person" part, if several people report a problem it lends credibility to the problem. It may not even be a code bug, but may simply involve clarifying the documentation.

True, but you'll just end up closing real bugs as "didn't submit a test case" if you follow a procedure like MySql. And you'll think you have fewer bugs than you really do.

It's much better to leave them as "unconfirmed" or similar, so that other people can find them and add their own details or test cases. (Of course, I do assume that a project with a lot of "unconfirmed" bugs has no one even looking at the bug database, so it's a double-edged sword.)

> In this case, though... It seems only 1 person has experienced this, and didn't care enough to even reply back. Closing it due to inactivity doesn't seem to be wrong, to me.

The blog post linked to two other reports of the same issue (all closed or ignored), and the author mentioned that he himself had run into it prior to turning up these abandoned reports on their bug-tracker.

And really, given the egregiousness of the symbol exporting issue, it would be nearly impossible for only one person to have run into it.

Many eyes make bugs shallow, because they simply ignore them.

Click the fork button. People that release free software have no obligation to their users; they wrote some code, made it available, and that is that. That's all free software is about: instead of being at the mercy of some Supreme Entity that makes your software, you have the power to do anything that Supreme Entity does. Fix the bug. Pay someone to fix the bug. Write your own database, and include the parts of MySQL that you like.

People who dedicate their time and money to hosting free software are not the ones to blame for your problems. Yup, they made a fucking dumb coding error that's costing you millions of dollars a second. But that's your problem, not theirs. All they did was share their creative work for your enjoyment; if you don't enjoy it, it's your problem.

As free software becomes more popular, people are forgetting what it means. It means that everyone has the same opportunity as the original author to fix stuff and freely share their fixes. It doesn't mean that the author has to do whatever you tell them to.

  It doesn't mean that the author has to do whatever you tell them to.

Right. Likewise, you're not obligated to help people pick things up or hold doors open for people. But you do it because it's a reasonable response. The maintainer had the right to respond how he did, that doesn't mean he should have, if he was interested in building rapport with the community, or improving the product. (This is sort of how companies have the right to provide poor customer service, but may prefer to yield that right even at added costs.) This is about bug reporting etiquette and the fact that being uptight about code sample procedures may be in bounds, but also counterproductive.

The blog post is not about someone unhappy that some feature was not implemented or some bug wasn't fixed. It's about how feedback is being treated. That doesn't change when you fork a project. In fact, the whole point of such a blog post is to explain how this would unnecessarily, and at a loss to all those involved, lead to forking. You're trotting out an old hobby horse without properly considering the problem. That just leads to the boring 'forking can't solve everything and also causes problems' debate.

MySQL people should see the following keynote: Being Your Best Asset and Not Your Worst Enemy - http://confreaks.net/videos/350-gogaruco2010-being-your-best...

Not just bugs, and not just technical issues: don't deal with reports from the community about problems with any part of your service like this.

I'm gonna get downvoted for this, but... Am I the only one who disagrees? To me this post should be titled "How not to file a bug for an open source project"·

A good bug report should include:

- A reproducible test case - ALWAYS

- Expected output and failed output

- The exact version of the software in question (preferably git commit hash or equivalent). "Whatever shipped with ubuntu 9.04" is not a version number.

- This is optional: A patch to fix the issue

In this case the patch should have also included objdump (or similar) dumps of the libraries the author has and a list of all functions exported that should not be (e.g. everything not ^mysql_.*).

Although this bug report is valid and describes a real issue, it has to be manually confirmed as an issue by a dev. This will take 5 or so minutes, which is too long to handle any significant volume of bug reports.

I'm sure MySQL/Oracle has commercial support available if you need service. If you need help from the open source community you need to be a part of the community and do your part of the job - you're not a paying customer. A well reported bug is a half fixed bug.

in a vaccuum, yes, every codebase should be perfect and every bug should be addressed. in real life, the codebase is aligned with the business needs of the maintainers. mysql's codebase may be sloppy, but nobody else seems to care about this particular issue, and if they do it will be +1'd until it gets fixed.

From the perspective of the MySQL developers this may be the only way to handle feedback. If a lot of people use your software you're probably going to get a significant amount of bug reports.

If I'm in the shoes of the MySQL bug triage team you have many things to do: research important bugs, relay them to the development team or internal stakeholder, and to consolidate bugs. I don't know the details but user bug reports might be like drinking out of a fire hose and the current process of asking for more specifics and timing-out bug reports may be their personal way of handling them.

I don't think just closing bugs without a solution is ever acceptable. The end-goal is increasing user satisfaction with your software. If you close a bug without resolution, you're not satisfying users. Closing this bug they way they did only improves some QA benchmarks, it doesn't actually satisfy any users.

Reply on news.ycombinator.com