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. >>> 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. (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. (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. 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)
