Backing out the code was a suggestion, not a rule. What is appropriate
I think depends upon the situation.
My main point is it would be good to have the information made available
to us in a timely and "in-your-face" way -- we don't have to go
searching for it, and we find out right away -- so we can discuss it as
a community and try to make the right decision.
David
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I think the same could be done for code coverage regressions. If a new
chunk of code is checked in and the numbers drop way way down for a
given module, I think that is cause for concern and a committer could
reasonably insist that the feature is not sufficiently tested and back
out the change, or at least block any future checkins in that area until
enough tests are provided.
So we could have applied this rule to JDBC 4.0 checkins. JDBC 4.0 code
was checked in, the code coverage numbers decreased and could not
increase until the tests could run under JDBC 4.0.
In this case requiring the JDBC 4.0 changes be backed out until all the
tests ran under JBDC 4.0 seems too drastic. Goes against the model of
incremental development.
Dan.
