<div dir="ltr"><div dir="ltr">On Mon, Jul 21, 2025 at 6:26 PM josh <<a href="mailto:joshnatis0@gmail.com">joshnatis0@gmail.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, July 21, 2025, Chet Ramey via COFF <<a href="mailto:coff@tuhs.org" target="_blank">coff@tuhs.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/21/25 11:27 AM, Paul Winalski wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When writing all but the most trivial bug fixes I always put in a comment referring to the bug report number.  This helps with what can otherwise be a perplexing problem:  "why is this bit of code there?"<br>
</blockquote>
<br>
I put those in the change log entries.<br>
</blockquote><div><br></div><div>Does anyone else feel like this is still an unsolved problem?</div><div><br></div></blockquote><div>Yes.  Change tracking is just one facet of the larger problem of source code control and configuration management.  The first change tracking programs such as SCCS and DEC CMS tracked changes on a per-file basis.  If a change set involved more than one file, you had to track that information elsewhere.  Later change tracking systems added the concept of a change set.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></div>There is a lot to say about a change which would be extraneous to include in the code as comments — real-world context (as mentioned), trade-offs considered / why specific implementation decisions were made, explanation and annotation, potential future steps, testing/validation, and even rich media demonstrating things that may be hard to express in text.[1]<div><br></div></blockquote><div>In the shops I've worked at we used our bug-tracking system for that. At DEC we created pseudo-"bugs" in the tracking system for new development.  That way all of the information about what was changed and why was in one place.</div><div><br></div><div>-Paul W.<br></div></div></div>