[petsc-dev] Pushing non-working code

[Matthew Knepley]

On Sun, Feb 3, 2013 at 1:38 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Sun, Feb 3, 2013 at 1:29 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>
>> Hi Matt,
>>
>>
>> >     ---
>>
>>>     '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.
>>>
>>
>> Yes, I know, and you may have good reasons for that. We don't get any
>> pointers on these, though.
>
>
> I am saying it is easy for me to ignore warnings and incomplete pushes
> here. I am not sure what documentation
> you want. I do this every day.
>
>
>>      ---
>>>     '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.
>>>
>>
>> I'm aware of the definition of 'gain', thanks. I'm also aware of the fact
>> that you can easily create tons of gain by just using an arbitrary baseline.
>
>
> I was not being flippant here, but noting that the baseline is the current
> system which is being criticized.
>
>
>>
>>  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.
>>>
>>
>> New developers are usually willing to adapt to the workflow of the
>> project anyways, particularly if it follows established 'best practices'.
>> 'Compile cleanly at high warning levels' is one of them, so we are not
>> proposing something radically new.
>
>
> That rationale could be used to justify any scheme.
>
> My point is that there could also be many people with my attitude, and
> therefore I do not think
> a poll on this thread is a defense.
>
>
>>      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.
>>>
>>
>> I'm not calling you inflexible here. I just said that I don't want
>> *this*, i.e. the principle, to become our overall dictum.
>>
>> Since I'm on this list (less than a year) I regularly observed lots of
>> resistance with respect to any changes of workflow. This can be either due
>> to bad suggestions for improvement, or due to the emerge of an overly
>> conservative development culture. I'm fine with the first option, but I
>> fear the latter (not only PETSc-related).
>
>
One more comment on an "overly conservative development culture". It is
easy to see pushback on changes as
unwarranted caution, whereas the other side sees it as preservation of
desirable attributes. I think it would be just
as easy to interpret the present changes as overly proscriptive, which are
of course seen as improvements by the
proposers.

   Matt


> Since you have been on the list, you will note that there is vigorous
> debate for all changes.
>
>    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
>



-- 
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/381ba7ef/attachment.html>