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
