[petsc-dev] Pushing non-working code

[Karl Rupp]

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


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

Best regards,
Karli