The best bug reports are pull requests | Hacker News Reader

The best bug reports are pull requests

ayende.com

36 pointsrayvega9 comments

A friend of mine has a little poster by his wall that says, "Stacktrace or GTFO" for all people who give him bug reports. It follows the same mentality as this - the more resources you can provide a developer for a bug report, the a.) faster it'll be fixed and b.) the happier the developer will be. I think you're right though, a pull request is pretty much like spoon feeding the bug to the developer. That said, I think he's right in that it might clutter up the repo a bit with bug examples - if pull reqs for bugs become common place (and I hope they do) it'd be nice to have a way to classify them as such (or perhaps there is a way that I don't know about yet?).

Some developers have a mentality that if not enough information was provided in the bug report then it's not a real bug.

They are wrong.

Just because you didn't get enough information to reproduce and/or fix it, doesn't mean it's not there.

But, it does mean there is nothing you can can do about it. (Obviously try to get clarification and more info, etc. this is assuming you were not able to.)

Nevertheless, in the back of your mind you should try to remember the bug and maybe you'll come across something that will let you figure out what it was.

This doesn't scale so well for OSS projects, but if it's paid work and the bug came from your client then you better track such things, even if you can't immediately fix them.

I get both ends of this.

On one side, I have trouble getting information out of people ("It had an error" ... "What did it do?" ... "I don't know anything about computers, so I clicked okay. Can't you just fix it?") and on the other, some of the people I report things to aren't willing to even try to reproduce bugs ("I need 8,000 different files, screenshots, etc. of the bug in action, which will require you to shut down production for an hour" ... "Can't you just look at the code for X? It fails every time with the same behavior." ... "No, I really need you to waste a lot of time on this because I'm way too busy to implement any kind of logging." ... "No wonder you won't let anyone else have access to your bug tracker. Something tells me it's a sticky note or whiteboard based system.")

I completely understand how people can fail to report enough information to give anyone any hope of finding the bug, but it's frustrating when you know you've got a good bug report and the developer doesn't want to listen to you.

You should tell your coworker that plenty of bugs don't cause stacktraces. In fact, most of them. :-)

It could be a trace of the Human Stack as well (i.e. steps to reproduce).

They're both a list of steps taken to get to a point in the system.

> A friend of mine has a little poster by his wall that says, "Stacktrace or GTFO"

This one? http://imgur.com/jacoj

That'd make an awesome poster.

I doubt pull requests with failing tests for bugs are ever going to be that common (unless you have a really good testing department between you and the end user capable of writing the tests) but if they did then the correct way of dealing with them would be to identify the bug, correct the problem in the source and create / modify the test so that your test covers the general failure mode.

In general, when I have an issue, I try to produce a small snippet of code that shows the problem. I haven't done it as a unit test before, but I don't think I've ever submitted a bug report to a project that has them...

It helps both me and the developer, because the developer can run the code and see if he fixed -my- problem, rather than -a- problem, and I can run it afterwards to verify that it's fixed. I've also had it show that the same code will hit many bugs before it works... This allows the developer to fix it all the way down.

*pull requests containing a new, failing test. Love it.

Reply on news.ycombinator.com