David E Jones wrote: > On Mar 19, 2010, at 12:04 PM, Adam Heath wrote: > >> Jacopo Cappellato wrote: >>> On Mar 19, 2010, at 6:43 PM, Adam Heath wrote: >>> >>>> [email protected] wrote: >>>>> Author: jacopoc >>>>> Date: Fri Mar 19 17:23:15 2010 >>>>> New Revision: 925342 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=925342&view=rev >>>>> Log: >>>>> Improved search capabilities of the work effort calendar screens; >>>>> converted ftl template to form widget. >>>> This should have been 2 commits, they aren't related. >>>> >>> I enhanced the search features by replacing the existing ftl forms (one for >>> each search field) with *one* single widget form: in this way searches can >>> be done with multiple constraints. >>> Are you saying that instead I should have: >>> >>> 1) converted the ftl forms into widget forms in order to preserve the >>> original limitations >>> 2) aggregate the widget forms into one widget form in order to implement >>> the new feature >>> >>> ? >>> >>> This is the most ridiculous thing I have ever heard. Or maybe it is a new >>> *policy*? >> The reason it's good to split it, is that the conversion from ftl to >> widget might introduce bugs, just the conversion itself. Trying to >> track the problem down in the future when the bug is actually found is >> much simpler to do when the change is isolated. >> >> All you can say about any bit of code, is that you've fixed all >> *known* bugs. There could be an unknown bug in the conversion, that >> is only discovered in the future. The split makes it simpler to track >> down. > > Adam: Maybe you need to consider a different approach to debugging, as I've > mentioned before, like understanding the code. This stuff is all > deterministic, there is no reason to resort to experimentation.
(general discussion) Not going to happen, and here's why. Right now, you understand it, I understand, Jimbo over there understands it. Who cares about right now. One year from now, will you, me, Jimbo, and Billy Bob understand it? Billy Bob is a new guy that wasn't involved in this discussion, or in the change that happened, but he sees some problem that he is trying to track down. Three years from now, you're dead, I'm in an insane asylum, and Jack has a problem. Jimbo no longer works on ofbiz, and Billy Bob decided to switch to another platform. What is poor little Jack supposed to do? How can he debug it? He can't ask you, me, or Jimbo. Billy Bob could care less about ofbiz, as he decided to switch away from ofbiz because of the problem he found 2 years hence. Splitting commits into singleton, separate changes makes the job easier for people who do not have an extremely deep understanding of the code. And why is that a bad thing? One of the things I am very good at, is debugging other code, site unseen, going into whatever program, whatever code storage policies they have, and finding the actual line that is either printing the error, or causing some exception or core dump. This kind of debugging is fairly straight forward to do. Fixing the problem once the target line is identified, however, is much more difficult, and requires a deep understanding of the target code. But, if I can tell the original developers what line is the cause, what commit was the cause, it makes their job also easier.
