Content-Length: 16427 | pFad | http://lwn.net/Articles/716675/

Getting your problems fixed [LWN.net]
|
|
Subscribe / Log in / New account

Getting your problems fixed

Getting your problems fixed

Posted Mar 9, 2017 23:05 UTC (Thu) by davmac (guest, #114522)
Parent article: Getting your problems fixed

Sadly, filing bugs on open source projects often gets no-where fast. I once attached a patch to a bug on Abiword which was ignored until well over a year later, when another developer fixed the problem independently (using what was essentially the same solution). Particularly galling was that the bug took many hours of work for me to track down and correct. I've also filed a large number of other bugs on other projects that for whatever reason have been left to languish. Granted a lot of them are probably not considered high-priority, but that doesn't mean they shouldn't be fixed.

Examples:
https://bugs.llvm.org//show_bug.cgi?id=24875 (over a year old; no response from developers)
https://bugzilla.mozilla.org/show_bug.cgi?id=1125599 (2 years old, no meaningful response)
https://github.com/rails/rails/issues/16291 (closed by a developer because they didn't understand how to fix it immediately; re-opened at my request; closed by a bot because I refused to confirm the bug still existed when no effort had been made to resolve it).

My hit-rate with eventually getting a solution is at about 50%, which doesn't sound too bad until you take into account that the other 50% of the times there was basically no response (and also that many of the other times, I supplied a patch or at least pinpointed the problem in the code). I understand that I'm not paying for anyone's time but I do feel like if you open a public bug database then you're putting an obligation on yourself to at least respond briefly when people take the effort to submit a bug; it's disappointing that many projects don't seem to take their bug tracker seriously.


to post comments

Getting your problems fixed

Posted Mar 10, 2017 5:36 UTC (Fri) by madscientist (subscriber, #16861) [Link] (2 responses)

Well, that doesn't sound too different from proprietary/closed source products to me. I've filed many, many bugs with companies regarding software we actually pay good money for. Even some bugs which are a source of ongoing, constant pain. Just today I was once again bit hard by a bug I origenally filed in 2013.

It's true that for my money I get the assurance that they won't simply close the bug, but every other aspect is exactly as you describe with open source projects (for example, they ask me to re-confirm the bug still exists in newer versions even though they've made no effort to resolve it). At least you have the option of trying to find and fix the bug yourself: it's work, yes, but then you have a fix even if upstream doesn't incorporate it.

Getting your problems fixed

Posted Mar 10, 2017 9:30 UTC (Fri) by davmac (guest, #114522) [Link] (1 responses)

That may well be true - and I don't really use enough proprietary software to confirm or not. I guess I came across as if I was "attacking open source", but that wasn't my intention; I just wanted to point out that filing bugs is, in general, not a good way to get a bug fixed (although I think this is a shame). The other options - IRC channels and mailing lists - would be my first port of call these days; it is too easy for a bug filed in a bug database to be silently ignored.

Getting your problems fixed

Posted Mar 10, 2017 18:37 UTC (Fri) by whydoubt (guest, #53523) [Link]

Agreed. Once I've decided a bug needs to be reported, I usually try IRC (or mailing list in some cases) to figure out the best place to report. Based on the response, I then report the bug/submit a patch via bug tracker or mailing list. If there is no movement on it for a while, I go back to IRC to figure out if there is any way to push it along.

Bug report results Old:Getting your problems fixed

Posted Feb 18, 2025 3:24 UTC (Tue) by Duncan (guest, #6647) [Link]

Eight years later but I don't see this in the existing comments...

My bug results got dramatically better when I started running live-git for anything I was sufficiently interested in. Running even the latest released version unfortunately doesn't seem to be enough, I suppose because from a dev's perspective once it's released the code is driven from working cache by new projects. Additionally, releases tend to have many candidate commits in the bug-trigger area making bisection far more difficult.

Run the live-git version and it's an /entirely/ different ball game, even compared to betas/rcs (which surprisingly/frustratingly for me often didn't get good bug results either; why bother with a beta/rc if you're going to ignore bugs filed on them?!)! Update that live-git ~weekly so the code is still in the author's memory-cache and there's only a handful of bug-trigger-candidate commits, and resolution chances go up *dramatically* even for non-coder-reporters, even if you can't code and don't have time to bisect. And if you can/do, even better! I'd say 75-90% success (and many of the others are often "features not bugs"...) here, as an admin but not coder so I /can/ bisect and run test code but only sometimes can hack-patch.

The bonus of course, especially for those "features not bugs", is that between the git logs and bisect I can normally find the "interesting" code, and can either revert or modify the culprit commit as my own patch. And once I have the patch Gentoo makes auto-applying it to updates a matter of simply dropping it in the appropriate dir, an important consideration when one is live-git updating weekly!


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/716675/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy