Scott Gray wrote: > Wow, how about we all calm it down a few levels, despite the biblical > references I don't think the end is nigh quite just yet and it's safe to > relax a little bit. > > One downside of buildbot is that everybody is acutely aware of any failures > that occur regardless of how quickly they are fixed, but hopefully that will > promote better practices without the need for this sort of intervention and > the subsequent storm that seems to ensue. > > Regards > Scott > > On 2/02/2010, at 10:22 PM, David E Jones wrote: > >> On Feb 2, 2010, at 11:53 PM, Adam Heath wrote: >> >>> David E Jones wrote: >>>> On Feb 2, 2010, at 11:07 PM, Adam Heath wrote: >>>> >>>>> [email protected] wrote: >>>>>> Author: hansbak >>>>>> Date: Wed Feb 3 03:58:13 2010 >>>>>> New Revision: 905878 >>>>>> >>>>>> URL: http://svn.apache.org/viewvc?rev=905878&view=rev >>>>>> Log: >>>>>> fix build error reported by buildbot >>>>> How did you not discover this before you commited it? Did you not do >>>>> a clean-all/run-install/run-tests? For such a large commit, this kind >>>>> of error is inexcusable. >>>> Come now Cardinal Heath, some level of forgiveness can surely be found in >>>> even the coldest of hearts, and do we not all hope that even the most >>>> depraved and ignorant among us is deserving of some level of empathy? >>> Seriously? Really? You are suggesting that renaming a >>> component(which is essentially what this is), shouldn't do a standard >>> clean/test run? >> That's absolutely ridiculous. I neither said nor implied anything of the >> sort. Get your head out of...
Um, you saying I should forgive this error implies that the error isn't that big a deal, and that it was ok that it happened, and we should just pat Hans on the back, and put on our big red clown smiles. >>> There were several other things I could have commentted on, code >>> quality, design, whatever. Those would have been opinions, when you >>> really got down to it. I didn't. I commented on procedure. >> Great, so you chose a personal attack over reviewing things that might >> actually be helpful. If that's the high road I'll stick to the low one. (pre-script; this paragraph was written last, after everything else)Do you not pay attention? I try to not do personal attacks, and word things such that they apply to anyone who may be happening to read it. This applies to the time when the email is written, and years later when someone does a google search and finds the mail, or, when someone reads a changelog at some point in the future. I do this consciously. I have done it repeatedly on this list. I have explained it as well. But this was one case where I did not do this, and again, did it on purpose. I'm quite polite during these discussions. Yet, when I point out a very obvious problem, one that does get repeated by Hans, instead of saying that Hans made a mistake, you do a personal attack on me. Again, and I really really really hate saying this, but you need to take your head of out of your ass(damn it, I wish I hadn't had to say that; sometimes, a slap in the face is the only way to get some people to shut the hell up, and think about what they are saying, and how it is coming across). You, David, came across *entirely* to strong. How could I comment on things I know nothing about? I don't use any ebay code in any customer deployment. But the procedure I commented on is followed by everyone. I reference the doc I posted a while back, about being courteous to others, trying to do no harm. I choose to comment on what I know, and that is a simple clean-all/compile phase. Yes, I could have gone into his large commit, looking over stylistic issues; ie, maybe there is a spot that UtilValidate.isEmpty could be used, or maybe there are tabs instead of spaces, or a way to use an enhanced for loop. That's not the point. The point was that this commit broke ofbiz for others who are doing work on it. Stylistic issues with the code don't affect anyone else, other than the original author. Those can be discussed later. Broken compiles are just unforgivable. Outside of the occasional issue(which, as I have maintained, depends on the sizze of the change). For reference, I just did a revert(using git, love this tool), and it did fail. Yes, this may not have been detected if you were doing a commit from a dirty checkout. But I do pristine testing before committing, can't others, esp. for larger commits. Wholesale moving of entire code subdirectories is an extremely destabilising event, and certain steps should be taken to limit how much extra work others in the project have to do. >>> I admit I haven't been perfect with commits. I have even committed >>> stuff that has failed to compile. I admit I'm not perfect. However, >>> the probability of that decreases with the size of the commit/change. >> I was going to stop above, but sorry, this is bull shit and a totally >> ridiculous idea. In fact, haven't you even caused problems BECAUSE of trying >> stick to the evidently sanctified approach of splitting your commits into >> tiny chunks? >> >> What's more... do you test after each commit to make sure that interim >> updates won't be broken? How can you possibly say that this will cause less >> problems. Um, very often I do. For any large commit set where I know it could cause problems with external entities, I do interim testing at each commit level, clean-all/run-install/run-tests. This is why I love git, because it makes this job simpler for me. I don't do it for all my flood commits, as generally the earlier commits in a series are not changing code, just adding new functions. Even before I started using git, even before I ever got involved in ofbiz(this is going back 5+ years), I would do a bunch of work on some project, then flood commit manually, copying my svn checkout, cleaning it so it was completely pristine, and manually retyping whatever feature I had done into separate commits. I did this often when I was working on dpkg(yes, the dpkg in debian).
