[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