[petsc-dev] Pushing non-working code

[Matthew Knepley]

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130203/c7cd8b89/attachment.html>