I've been working recently with a group of "cloned bugs" and wanted to explain a bit about what they are and why it takes so long to deal with them. In this case, I hope you will understand why going slow here is OK.
We have a code base that lives in what we call a branch. This is repository in which all OneNote code exists and it is governed by a process that limits the changes to it. We build our code every day and the process that limits changes helps prevent instability from being introduced (the process requires code reviews, testing, etc… and I won't go into the gory details here). The point to remember here is that our code is kept in a known good state.
Every so often, we want to spin off a separate branch. Maybe we want to contemplate a large change that needs more testing than normal and we just want to isolate our changes from everyone else. We will call that a fork and what we do is "snapshot" the original code on some date and then make our own repository for changes. This way the main branch keeps going along and we have our own fork in which to work on our changes.
It looks like this:
It's a pretty simple drawing. We are working on the upper red branch in my example.
Generally, we will only work on new code in our fork and leave the snapshot we took unchanged. That will make it much easier to port all our changes from our fork back to the Main branch once we are done. But every so often, we will find a core bug that we need to fix in both our fork and the main branch. In that case, we want to make the exact same code change in two different places.
We enter a bug against whichever branch we used to find the bug - let's say we found it in the red fork - and we target a fix for that branch. When we get ready to check it in, our tools will create a clone of that bug with the only difference being that the bug is set to be fixed in the Main branch.
Then when we check in, we have two bugs to resolve. One was the bug we entered and will ensure the fix gets taken in the red fork, the other is the clone bug that ensures the fix will go into the Main branch. It is a useful reminder to use for keeping our code base in sync.
It can be time consuming but is critical for the science of "branchology" (I just made up that word).
More on this if you want, just let me know. This can be quite tedious and I understand wanting to focus on other things.
Questions, comments, concerns and criticisms always welcome, John