Hello BJ,FYI we have done extensive testing before making the Java Code as the default option.
Total of 5 members were involved in this process. Here are my thoughts:
1) While committing the code, the exact rephrased word was there in my mind. My bad I wrote it in not a good way.
-------------------------------------- However, you could also interpret this a different way, and give him the benefit of the doubt as to intent and process: "Changing the default to the new implementation which now has more features than the previous one and has been tested in a development/testing environment; would appreciate collaboration on further development of this and welcome others to test it according to their requirements, and we'll be happy to work with them on making it work for them even if their requirements are different than the ones we are working from." -------------------------------------- Thanks David for making it more clear. I agree that it depends on the individual how he / she interpret the things.If you are watching the progress or reviewing the work coming on the way then only you can comment on the things to get improved results. Although comments coming on the other hand creates confusion and waste the time of each individual IMO.
2) In my log I mentioned a word "Extensive". What does it mean? It means we have tested it and we would be thankful to have help from others to review and comment on the work. At the same time we should continue our testing in more different different way. You won't believe but I had thought about this single word "Extensive" three or four times before committing the code.
3) We have only reused the things in Google Checkout. Like we have called helper methods, services etc.
We haven't made any changes in the Existing artifact of other components.Before committing the code we found that there were no build fail and there were no functionality break .
4) I will wait for the three negative vote on my last commit to make the Java based implementation as the default option. For a moment we have negative vote. And if we get two more vote then I will revert my changes.
If we talk about collaboration then few questions are coming in my mind that I would like to ask from you BJ.
-- How many times do you think that your reply contains good enough details for a person to move in a right direction instead of deviating each individual here or there? -- How many times you read your email before posting it on the mailing list? -- How many times do you think that your email would be well understood by someone in a first pass? -- How many times do you think that the email written by you is properly formated?
I assure you all that in future I will think more and more before writing anything in the commit logs.
-- Ashish BJ Freeman wrote:
I apologize to Ashish that I chose his to make a stand on. I was not meant to be a personal attack on him. it was the statement only that triggered it. I dislike being a unwilling guinea pig. and I dislike debugging some else's code because they have not. now if someone has tested and thinks they have the bugs out, that is different. But I see in the commits a lot of changes becuase error are found. BTW this is not the first time i have mentioned this. Actually I started this back in 2003. yes you have brought it up also. even had a lively discussion about testing. as you may have noticed I don't demand things work a certain way I may express an opinion. I used to offer to put the things in, incase someone wanted to use them, but I do the things I want, the way I want, on my own version. and yes i do testing all the time, it runs day after day after each change. David E Jones sent the following on 5/30/2009 6:01 PM:On May 30, 2009, at 4:22 PM, BJ Freeman wrote:I see commits like the one I just commented on that says lets open this so it can be tested. The "do no harm" comes to mindIs it the contents of the commit or the comment from Ashish that bothered you? I'll agree that his comment ("Reason of enabling this new implementation is that we should get bugs in extensive testing and code will become more stable") was poorly phrased and sounds like a lazy approach to contributing things. However, you could also interpret this a different way, and give him the benefit of the doubt as to intent and process: "Changing the default to the new implementation which now has more features than the previous one and has been tested in a development/testing environment; would appreciate collaboration on further development of this and welcome others to test it according to their requirements, and we'll be happy to work with them on making it work for them even if their requirements are different than the ones we are working from." I might be interpreting this a little too generously, but without evidence to the contrary this is what I'm happy to believe. What I have more of a problem with is things like "I didn't write this, I haven't tested it, but since not very people complain about Commit-Then-Review in it goes!" IMO the CTR pattern, especially for anything widely used, is generally pretty rude and not good community etiquette. Of course, that's my pet-peeve and I know that I have a hard time being "generous" with people when I see it... but unless I see something specific that causes a problem I usually try to refrain from commenting...Now here is my full thoughts on this. i think we have enough manpower at this point that we should require that a test unit be used for testing before submitting to the trunk. then allow it to be committed along with the code that was tested by the test unit.The project technically has zero manpower... it's all volunteer. That means that if no one cares enough about testing to work on it and contribute (and/or improve) automated tests then there won't be any tests. However things turn out, the management of the project is based on "meritocracy." There are lots of different ways of approaching automated tests (and I say "automated" and not "unit" because it would be great to have a wide variety of automated tests and not just unit type/level tests). At this point we have pretty good support for automated unit tests (basically service level and below), but not such good support for UI-level tests, though these are definitely getting closer. Anyway, at the conference last year in New Orleans a number of ideas and approaches were discussed (and I think all of these have been discussed over time on the mailing lists too). The one I like the most, and that I've mentioned on this mailing list, is to encourage people that want to have a certain thing work a certain way to contribute an automated test for that. In some cases people who contribute automated tests will be the same as those who develop things, and probably in many cases it will be people who were not involved in the development. The basic idea is simple: if you want something to work a certain way, contribute an automated test that verifies it; if you manage to get your unit test committed then you have an easy basis to complain that something is broken, and you have a "foot in the door" for making OFBiz function the way YOU want it to. -David
smime.p7s
Description: S/MIME Cryptographic Signature
