[petsc-dev] Pushing non-working code

[Jed Brown]

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

> How do you identify what the feature is when it's in 10 commits
>> interspersed over 200 in the history. My claim is that you should make
>> those 10 commits on top of each other without merging (unless you need
>> sometIhing specific that was pushed to petsc-dev) and merge when it's
>> complete. Pushing to petsc-dev should _mean_ that it's ready for review.
>> This does not take more work.
>>
>
> Again, hyperbole is not useful. This is a single commit, where I add
> functionality to a few functions for a single purpose.


Matt, I was referring to the general "push as checkpoint" workflow rather
than that single commit with the memory leak. While I think that patch
could have been split into "generalize existing functionality" followed by
"add new functionality", it's a bug that could have happened to anyone and
is more reliably caught by proper testing.

I've given a lot of reasons why "push as checkpoint" is bad for everyone
else working on the project. You have not explained how it helps so much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130203/e8dd5908/attachment.html>