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
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.
Getting your problems fixed
Posted Mar 10, 2017 5:36 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (2 responses)
Posted Mar 10, 2017 5:36 UTC (Fri) by madscientist (subscriber, #16861) [Link] (2 responses)
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)
Posted Mar 10, 2017 9:30 UTC (Fri) by davmac (guest, #114522) [Link] (1 responses)
Getting your problems fixed
Posted Mar 10, 2017 18:37 UTC (Fri)
by whydoubt (guest, #53523)
[Link]
Posted Mar 10, 2017 18:37 UTC (Fri) by whydoubt (guest, #53523) [Link]
Bug report results Old:Getting your problems fixed
Posted Feb 18, 2025 3:24 UTC (Tue)
by Duncan (guest, #6647)
[Link]
Posted Feb 18, 2025 3:24 UTC (Tue) by Duncan (guest, #6647) [Link]
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!