[petsc-dev] Pushing non-working code

Matthew Knepley knepley at gmail.com
Sun Feb 3 12:06:03 CST 2013


On Sun, Feb 3, 2013 at 12:59 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:

> Hi Matt,
>
>
> On 02/03/2013 11:37 AM, Matthew Knepley wrote:
>
>>
>>     +1 for Sean. I'm tired of carefully writing down the points I'm
>>     trying to make, carefully (re-)reading through what I've written,
>>     and then just to get a generic 'how does this relate to XYZ'-type of
>>     answer without really addressing anything I've raised.
>>
>>
>> I find it tiring to continually make points that someone does not want
>> to hear, and thus dismissed without recognizing
>> that a point was made.
>>
>
> We would like to hear/read more about why you think this is indeed a
> point. Examples in this thread:
>
> ---
> 'I don't think there is any
>
> evidence that it increases productivity, and quite a lot that it is rather
> marginal on that score while increasing development
> costs. I do not see any effect from these kind of pushes. Does that mean
> my workflow is more robust, and we should force
> it on everyone else?'
>
> *Why* do you see it? I would love to see that at least nailed down to an
> example from 'practice'.
>

I said "I do not see" above.


> ---
> 'I can quantify the losses from the changed you propose, which is all I
> need to do. There are no "gains" from a baseline. This is
> a point I have made multiple times. Changes must be justified.'
>
> *Why* are there no gains? The sentence is a bold statement. If you require
> us to quantify everything, you should do so with your own statements as
> well.
>

It is the definition of the word. Gains are defined in reference to
something. That something is the baseline.


> ---
> 'Its more work for me. Clearly you are asking me to do something I do not
> currently do. A loss.'
>
> *Why* is it a loss? Just because it's more work for you does not mean it's
> more work overall.
>

I am arguing from the same point of view as everyone in the discussion,
meaning I like my process and
and defending it. Your point is that its may be worse for me, but enough
better for you that it does not matter?
I would answer that if its worse for me, it could be worse for many
potential developers.


> Matt, it's not that we don't want to consider your points. The thing is
> that we want your justifications for the bold statements you (sometimes)
> make just in the same way you require us to justify or provide evidence for
> our own statements. I certainly agree with your principle of 'we don't need
> to change things just for the sake of changing', yet I don't want this to
> become an universal dictum which makes us as inflexible as a steel beam
> with respect to changes of our environment/community.
>

I think if you look at the history of the project, calling me "inflexible"
on PETSc development habits would be wrong.

   Matt


> Best regards,
> Karli
>
>


-- 
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/4bd53e42/attachment.html>


More information about the petsc-dev mailing list