[petsc-dev] Pushing non-working code

[Jed Brown]

On Sun, Feb 3, 2013 at 11:09 AM, Matthew Knepley <knepley at gmail.com> wrote:

> If the checkin you originally complained about the build did not fail and
> a memory leak did not appear. You
> still cannot explain what was wrong there, so you proceed to a different
> problem.
>

Users even write petsc-maint about the warnings. You did not address that
point.

Pushing as a checkpointing mechanism discourages review.


>
>
>> Since we make API changes in petsc-dev, people may need to update their
>> code. For example, I updated parmod last night and had to update a few
>> things for it to build, but then -malloc_dump told me about a memory leak.
>> If I was not a PETSc developer, should I have expected it to be due to a
>> bug in my code or a new bug in PETSc? As it turns out, you introduced the
>> memory leak as part of a bunch of other stuff
>>
>
> Yes, a memory leak did appear here. However, it appeared in a complete
> checkin that had a test to go with it,
>

Either that test did not actually run the code, or you didn't have
-malloc_dump in the test. (It should _always_ be used when testing.)


> exactly as you ask. We see that even that is insufficient sometimes to
> discover a minor bug like this. So your
> second example is really about the shortcomings of the strategy you
> propose.
>

Your patch did several things. It would have been easier to spot (though
not necessarily noticed) if the patch had been split apart.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130203/d97234f2/attachment.html>