<div dir="ltr">On Sun, Feb 3, 2013 at 1:29 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matt,<div class="im"><br>
<br>
>     ---<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    'I don't think there is any<br>
<br>
    evidence that it increases productivity, and quite a lot that it is<br>
    rather marginal on that score while increasing development<br>
    costs. I do not see any effect from these kind of pushes. Does that<br>
    mean my workflow is more robust, and we should force<br>
    it on everyone else?'<br>
<br>
    *Why* do you see it? I would love to see that at least nailed down<br>
    to an example from 'practice'.<br>
<br>
<br>
I said "I do not see" above.<br>
</blockquote>
<br></div>
Yes, I know, and you may have good reasons for that. We don't get any pointers on these, though.</blockquote><div><br></div><div style>I am saying it is easy for me to ignore warnings and incomplete pushes here. I am not sure what documentation</div>
<div style>you want. I do this every day.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    ---<br>
    'I can quantify the losses from the changed you propose, which is<br>
    all I need to do. There are no "gains" from a baseline. This is<br>
    a point I have made multiple times. Changes must be justified.'<br>
<br>
    *Why* are there no gains? The sentence is a bold statement. If you<br>
    require us to quantify everything, you should do so with your own<br>
    statements as well.<br>
<br>
<br>
It is the definition of the word. Gains are defined in reference to<br>
something. That something is the baseline.<br>
</blockquote>
<br></div>
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.</blockquote><div><br></div><div style>I was not being flippant here, but noting that the baseline is the current system which is being criticized.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am arguing from the same point of view as everyone in the discussion,<br>
meaning I like my process and<br>
and defending it. Your point is that its may be worse for me, but enough<br>
better for you that it does not matter?<br>
I would answer that if its worse for me, it could be worse for many<br>
potential developers.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div style>That rationale could be used to justify any scheme.</div><div style><br></div><div style>My point is that there could also be many people with my attitude, and therefore I do not think</div><div style>
a poll on this thread is a defense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    Matt, it's not that we don't want to consider your points. The thing<br>
    is that we want your justifications for the bold statements you<br>
    (sometimes) make just in the same way you require us to justify or<br>
    provide evidence for our own statements. I certainly agree with your<br>
    principle of 'we don't need to change things just for the sake of<br>
    changing', yet I don't want this to become an universal dictum which<br>
    makes us as inflexible as a steel beam with respect to changes of<br>
    our environment/community.<br>
<br>
<br>
I think if you look at the history of the project, calling me<br>
"inflexible" on PETSc development habits would be wrong.<br>
</blockquote>
<br></div>
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.<br>
<br>
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).<br>
</blockquote><div><br></div><div style>Since you have been on the list, you will note that there is vigorous debate for all changes.</div><div style><br></div><div style>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Best regards,<br>
Karli<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>