[petsc-dev] Pushing non-working code

[Matthew Knepley]

On Sun, Feb 3, 2013 at 12:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

>
> 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.
>

I did address. It would be great if people never pushed warnings. I try not
to.


> Pushing as a checkpointing mechanism discourages review.
>

Review should happend when the section is complete, but this is no way
implies that you should not
push until it is complete.


>
>>
>>> 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.)
>

Malloc dump was not on. It should be turned on in all tests automatically.


> 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.
>

It was a uniform change of a single functionality. It would be harder to
understand broken up.

  Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130203/d55afeaa/attachment.html>