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 mind
>
> Is 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
>
>
>
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
