| Computing desk | ||
|---|---|---|
| < March 27 | << Feb | March | Apr >> | March 29 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
March 28 Information
Hi, I found a bug in my code and applied a fix. This fix is incorrect and breaks lots of things, but it is a very natural thing to try. So I didn't commit the fix. But, I want to record the fix and the reason it didn't work so others don't repeat my mistake. How best to do this? Is it best to commit the faulty fix, then revert it? Or undo it? Or create a new branch and then just forget about that branch? What's the best way to do this? Robinh ( talk) 04:38, 28 March 2019 (UTC)
- The best way is to file a report, including the problem-description, the proposed patch, and an explanation of why it's insufficient; and report all these details using the bug tracking system that you and your fellow developers normally use. Provide enough detail for a reader to reproduce the bug and test the changes so they can independently see why it does, or does not, fully address the problem. If the easiest way to help future developers reproduce the bug is to commit the modified code to a branch: do so! In your bug report, record exactly how to check out that exact version of code. Include the exact commands you would type, the buttons you would press, and the steps you would follow to get, build, and test the project. Until the bug is resolved, leave the bug "open" in the bug-tracking system, and title it clearly. Think about how a future developer would stumble across this bug, and imagine that they would search the bug database for prior reports: make it easy for that hypothetical future developer to find your report by writing a very good bug report, including relevant, concise, searchable titles and keywords.
- You do already have a bug tracking system, right?
-
Nimur (
talk) 06:32, 28 March 2019 (UTC)
- Nimur, thanks for this. I use plain old github issues for bug tracking. It looks like creating a branch is the way forward, as it ticks all the boxes we need. But isn't it a bit wasteful to create a whole branch for a two-line patch (which is not even a good patch)?
Robinh (
talk) 07:55, 28 March 2019 (UTC)
- Exactly which resource are you worried about wasting?
Nimur (
talk) 13:44, 28 March 2019 (UTC)
- Time spent on enshrining a known unworkable bug-fix that breaks lots of things instead of using that time to solve the problem yourself if you can, or if you can't, to elucidate the bug for your peers, looks wasteful.
DroneB (
talk) 13:57, 28 March 2019 (UTC)
- The one exception is when [A] the bug has an obvious fix that anyone looking at it would try -- but the fix makes things worse. and [B] when the person making the report isn't skilled enough to be able to actually fix the bug -- or the bug is unfixable, as sometimes happens when someone tries to do something that computers cannot do, like look into the future.
- Time spent on enshrining a known unworkable bug-fix that breaks lots of things instead of using that time to solve the problem yourself if you can, or if you can't, to elucidate the bug for your peers, looks wasteful.
DroneB (
talk) 13:57, 28 March 2019 (UTC)
- Exactly which resource are you worried about wasting?
Nimur (
talk) 13:44, 28 March 2019 (UTC)
- Nimur, thanks for this. I use plain old github issues for bug tracking. It looks like creating a branch is the way forward, as it ticks all the boxes we need. But isn't it a bit wasteful to create a whole branch for a two-line patch (which is not even a good patch)?
Robinh (
talk) 07:55, 28 March 2019 (UTC)
- The looking into the future problem comes up surprisingly often. I recently wrote firmware for a toy and the spec had these requirements:
- If button A is pressed once, flash light B and play sound C
- Light B must start flashing and sound C must start playing within 1/10 of a second of button A being pressed.
- If button A is pressed twice within 3 seconds, flash light D and play sound E
- In the case of two button A presses, light B must stay dark and no part of sound C must play.
- (The customer was really wary about fragments of sounds playing because a previous toy would start playing one sound, then when another button was pushed suddenly switch to playing another sound, and so on. Some clever kid figured out a sequence of key presses that made it sound like it was saying a swear word and posted his discovery online.)
- Do you see the problem? The above requirements are asking the microcontroller to decide what to do now based on a possible button press that is a second or so in the future. --
Guy Macon (
talk) 15:34, 28 March 2019 (UTC)
- @Guy Macon I don't acknowledge that your [A] or [B] are exceptions to anything I or Nimur have said, as implied by your indent. Your toy programming problem would have been avoidable by a proper Use-case analysis before building the system with such an inadequate spec. As presented there is a conflict between a wanting a fast 0.1 sec response to a single press on button A and wanting a different response after up to 3 seconds to a double-press on button A. Consider instead responding differently to button A being released after a short (.1 to .5 sec) or a long (> .5 sec) press. DroneB ( talk) 14:43, 31 March 2019 (UTC)
- The looking into the future problem comes up surprisingly often. I recently wrote firmware for a toy and the spec had these requirements:
- (OP) DroneB puts his finger on my resource worry. Thanks for your support guys. In the end I realised that the correct patch was in fact my faulty fix but with a very minor modification. So I committed the correct patch, but with a comment to the effect "the code fragment below might look good but will break lots of things for this non-obvious reason". While I'm writing, does github issues count as a bug-tracking system? It is not mentioned at
Comparison of issue-tracking systems. Thanks,
Robinh (
talk) 18:55, 28 March 2019 (UTC)
- "Github" is a lot of things, including an issue tracker which certainly counts as an issue-tracking system. I am not sure why it is not present in Comparison_of_issue-tracking_systems (and neither is Gitlab).
- The Correct Way to go when setting out to fix some bug is to create a branch dedicated to fixing it, say
Tigraan/bugfix-1234and merge it back into whatever branch it was forked off once done. Hence, if you realise while trying a fix that it will not work, one possible option (and the one I would have gone for) is to commit it but obviously not merge it, and probably rename it to make way for the actual fix when it comes (e.g.Tigraan/not-a-correct-bugfix-1234; that way, you can reference it from the issue tracker and people can see diffs etc. but you have not ruined the main branch. - Taking the time to document what you tried and why it did not work is rarely "lost" in collaborative projects. If you do not produce an actual fix fairly quickly, other people may lose time taking the same exact steps and failing the same way; and even if the actual fix is out very quickly, a similar issue may pop up later on and knowledge of why the obvious fix fails would have to be rediscovered. Tigraan Click here to contact me 12:50, 29 March 2019 (UTC)
| Computing desk | ||
|---|---|---|
| < March 27 | << Feb | March | Apr >> | March 29 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
March 28 Information
Hi, I found a bug in my code and applied a fix. This fix is incorrect and breaks lots of things, but it is a very natural thing to try. So I didn't commit the fix. But, I want to record the fix and the reason it didn't work so others don't repeat my mistake. How best to do this? Is it best to commit the faulty fix, then revert it? Or undo it? Or create a new branch and then just forget about that branch? What's the best way to do this? Robinh ( talk) 04:38, 28 March 2019 (UTC)
- The best way is to file a report, including the problem-description, the proposed patch, and an explanation of why it's insufficient; and report all these details using the bug tracking system that you and your fellow developers normally use. Provide enough detail for a reader to reproduce the bug and test the changes so they can independently see why it does, or does not, fully address the problem. If the easiest way to help future developers reproduce the bug is to commit the modified code to a branch: do so! In your bug report, record exactly how to check out that exact version of code. Include the exact commands you would type, the buttons you would press, and the steps you would follow to get, build, and test the project. Until the bug is resolved, leave the bug "open" in the bug-tracking system, and title it clearly. Think about how a future developer would stumble across this bug, and imagine that they would search the bug database for prior reports: make it easy for that hypothetical future developer to find your report by writing a very good bug report, including relevant, concise, searchable titles and keywords.
- You do already have a bug tracking system, right?
-
Nimur (
talk) 06:32, 28 March 2019 (UTC)
- Nimur, thanks for this. I use plain old github issues for bug tracking. It looks like creating a branch is the way forward, as it ticks all the boxes we need. But isn't it a bit wasteful to create a whole branch for a two-line patch (which is not even a good patch)?
Robinh (
talk) 07:55, 28 March 2019 (UTC)
- Exactly which resource are you worried about wasting?
Nimur (
talk) 13:44, 28 March 2019 (UTC)
- Time spent on enshrining a known unworkable bug-fix that breaks lots of things instead of using that time to solve the problem yourself if you can, or if you can't, to elucidate the bug for your peers, looks wasteful.
DroneB (
talk) 13:57, 28 March 2019 (UTC)
- The one exception is when [A] the bug has an obvious fix that anyone looking at it would try -- but the fix makes things worse. and [B] when the person making the report isn't skilled enough to be able to actually fix the bug -- or the bug is unfixable, as sometimes happens when someone tries to do something that computers cannot do, like look into the future.
- Time spent on enshrining a known unworkable bug-fix that breaks lots of things instead of using that time to solve the problem yourself if you can, or if you can't, to elucidate the bug for your peers, looks wasteful.
DroneB (
talk) 13:57, 28 March 2019 (UTC)
- Exactly which resource are you worried about wasting?
Nimur (
talk) 13:44, 28 March 2019 (UTC)
- Nimur, thanks for this. I use plain old github issues for bug tracking. It looks like creating a branch is the way forward, as it ticks all the boxes we need. But isn't it a bit wasteful to create a whole branch for a two-line patch (which is not even a good patch)?
Robinh (
talk) 07:55, 28 March 2019 (UTC)
- The looking into the future problem comes up surprisingly often. I recently wrote firmware for a toy and the spec had these requirements:
- If button A is pressed once, flash light B and play sound C
- Light B must start flashing and sound C must start playing within 1/10 of a second of button A being pressed.
- If button A is pressed twice within 3 seconds, flash light D and play sound E
- In the case of two button A presses, light B must stay dark and no part of sound C must play.
- (The customer was really wary about fragments of sounds playing because a previous toy would start playing one sound, then when another button was pushed suddenly switch to playing another sound, and so on. Some clever kid figured out a sequence of key presses that made it sound like it was saying a swear word and posted his discovery online.)
- Do you see the problem? The above requirements are asking the microcontroller to decide what to do now based on a possible button press that is a second or so in the future. --
Guy Macon (
talk) 15:34, 28 March 2019 (UTC)
- @Guy Macon I don't acknowledge that your [A] or [B] are exceptions to anything I or Nimur have said, as implied by your indent. Your toy programming problem would have been avoidable by a proper Use-case analysis before building the system with such an inadequate spec. As presented there is a conflict between a wanting a fast 0.1 sec response to a single press on button A and wanting a different response after up to 3 seconds to a double-press on button A. Consider instead responding differently to button A being released after a short (.1 to .5 sec) or a long (> .5 sec) press. DroneB ( talk) 14:43, 31 March 2019 (UTC)
- The looking into the future problem comes up surprisingly often. I recently wrote firmware for a toy and the spec had these requirements:
- (OP) DroneB puts his finger on my resource worry. Thanks for your support guys. In the end I realised that the correct patch was in fact my faulty fix but with a very minor modification. So I committed the correct patch, but with a comment to the effect "the code fragment below might look good but will break lots of things for this non-obvious reason". While I'm writing, does github issues count as a bug-tracking system? It is not mentioned at
Comparison of issue-tracking systems. Thanks,
Robinh (
talk) 18:55, 28 March 2019 (UTC)
- "Github" is a lot of things, including an issue tracker which certainly counts as an issue-tracking system. I am not sure why it is not present in Comparison_of_issue-tracking_systems (and neither is Gitlab).
- The Correct Way to go when setting out to fix some bug is to create a branch dedicated to fixing it, say
Tigraan/bugfix-1234and merge it back into whatever branch it was forked off once done. Hence, if you realise while trying a fix that it will not work, one possible option (and the one I would have gone for) is to commit it but obviously not merge it, and probably rename it to make way for the actual fix when it comes (e.g.Tigraan/not-a-correct-bugfix-1234; that way, you can reference it from the issue tracker and people can see diffs etc. but you have not ruined the main branch. - Taking the time to document what you tried and why it did not work is rarely "lost" in collaborative projects. If you do not produce an actual fix fairly quickly, other people may lose time taking the same exact steps and failing the same way; and even if the actual fix is out very quickly, a similar issue may pop up later on and knowledge of why the obvious fix fails would have to be rediscovered. Tigraan Click here to contact me 12:50, 29 March 2019 (UTC)