Jacopo Cappellato wrote: > On Mar 19, 2010, at 8:50 PM, Adam Heath wrote: > >> things marked with (general) are meant to apply to anyone at all, >> anytime, working on anything. Not just those in ofbiz, not just >> Jacopo or me. >> >> Jacopo Cappellato wrote: >>> On Mar 19, 2010, at 8:13 PM, Adam Heath wrote: >>>>> Where is all this hostility coming from? I sent a simple message, >>>>> saying it should be split(not must). >>> And you were wrong. >> Ok, fine, no problem with that. But I still haven't seen a reason why >> it doesn't make sense to split it. Based on your own commit message, >> you have two separate changes. I didn't even have to look closely at >> what you were doing. My original email was mostly based on the >> message you typed in. > > Yes, I know that you just looked at the comment without looking at the code: > if you had looked at the code you would have realized what I did. > >>>>> You responded that it didn't >>>>> need to be, so I assumed that you hadn't seen any of my other emails >>>>> about this subject in the past(entirely possible, we are all busy, and >>>>> may not read everything). So, I happily repeated myself(I have no >>>>> problem doing that). >>> Ok, now I understand your point of view. Yes, I confirm that I also >>> appreciate the value of singleton commits and I always try to implement >>> them (like I did in this commit). >> Confirmation is nice, thanks. I believe you are the first one to >> actually do so. I don't require it, however. >> >> Generally, when I respond to a commit message, I don't look at who >> actually did it(again, repeating this). I look at *just* the single >> commit, all by its little lonesome self. And try to see if it can >> stand alone, without any other context. This is also because of the >> aforementioned procedure of futuring debugging, and the future person >> not having the full context when they start trying to figure things out. >> >> (general) >> >>>>> You then respond with this hostile email. >>> Yes, sorry if I have been too harsh; this happened because it took me a lot >>> of time and energy to reply to all your emails (and Ean's ones) in the last >>> couple of days and I was a bit disappointed (and surprised) when I had to >>> do it again after a such simple commit. >> Again, you may have considered it simple, but that is because you know >> different things then I do. This, as I've said, is a good thing. If >> someone asks a question, the very fact that they asked proves that >> they don't know something. If you *do* happen to know the answer, >> being combative/hostile/annoyed/whatever with them asking the question >> is a waste of time. > > Actually I was hostile because you didn't ask a question; your was a > statement: "This should have been 2 commits, they aren't related." > >> (general) >> >>>>> I see what I think are 2 separate changes in a single commit. That >>>>> part was obvious from the initial email I sent. If they weren't meant >>>>> to be split, then explain why. >>> In fact I did it; and it took time; and you could have realized it on your >>> own if you had spent more time reading my code. >> I don't know what you know. We all have different overlapping >> knowledge bases. If I knew everything you knew, I would be you. >> >> Yes, is is theoretically possible for any one of us to understand what >> any one else is doing. Unfortunately, in the real world, we all have >> limits, so we only know certain things. They may overlap slightly, >> but there will always be differences in our knowledge. >> >> As the author of the change, you are the best person in the world to >> answer any questions that someone may have about it. If someone else >> says nothing, then they probably have no clue at all about it. >> However, if someone does respond, that means they have a partial >> understanding, and just need to be slightly guided to the final >> conclusion. >> > > You know that I am always here to help as much as I can. > >> (general) >> >>>>> Again, it's obvious I didn't see why >>>>> they could be kept together. It was evident that I didn't see it, >>>>> otherwise, I wouldn't have sent that first email. >>> Of course, I understand you didn't realize. >>> >>>>> I've never said that this was a golden rule. >>> Actually I think it is a golden rule (it was not ironic) :-) >>> But of course I am flexible and if I would see you, or Adam or Scott or >>> David breaking it in one of their commits from time to time I would not >>> even think to mention this; I would imply you have good reasons for doing >>> this. Of course if I see committer X breaking this rule in each and every >>> commit I would instead take care of raising an objection. >> Ignoring a problem is the wrong approach. > > I don't see this as a problem, just a minor defect. In fact this will cause > (in the worst case scenario) a few more minutes to the hypothetical man of > the future to debug the code. > > By the way, I think we can close the discussion now, right?
Sure. > > I wish you a great weekend Yeah, I get to work on UtilCache unit tests. I finally figured out how to do Soft/Weak reference testing. The docs say this: * Soft cleared before Weak. * Soft cleared before OutOfMemory. * Weak cleared after main reference goes away. So, if there is no reference to the Soft value, the only way to force it to be cleared is to actually *cause* an OutOfMemoryError to occur. So, I allocate 128k length long array(1M in size), and store each array into a List<long[]>. Then, catch the OutOfMemoryError, and do a Thread.sleep, to allow background ReferenceQueues to be notified. Weak is done the same way, by doing a test while maintaining a hard-reference, and another one with that reference eliminated. Weaks will only be cleared when the OOM happens as well(the only guaranteed way). > > Jacopo > > >> Those who come up with >> policies/procedures/guidelines/nice-to-have may forget about them at >> times, and not do it correctly. This doesn't mean you shouldn't tell >> them about it. Go ahead and do so. They may have just made a simple, >> honest mistake. >> >> (general) >> >
