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