<div dir="ltr">On Sat, Feb 2, 2013 at 6:00 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Sat, Feb 2, 2013 at 4:38 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I would love it if people never pushed code with any bugs. This is possible, just not efficient. All changes to</div>

<div>workflow should be evaluated on this basis. For this particular change,</div>
<div><br></div><div>  1) It does not break the build</div><div><br></div><div>  2) Its a new feature, so does not break tests except the ones its supposed to</div><div><br></div><div>I do think warnings are annoying and people should endeavor to push code with no</div>


<div>warnings, but making this a requirement takes away flexibility while providing nothing</div><div>I can see except lack of Jed Annoyance. The claim that you are code reviewing this</div><div>push is false on its face.</div>


<div><br></div><div>I think this play into a larger issue. Does the increased process burden you are recommending</div><div>actually bring increased productivity. That the answer is yes is not at all clear. It is easy to make</div>


<div>the mistake that because something sounds good and "right" that you should do it. This dooms</div><div>most CS projects.</div><div></div></blockquote></div><br></div>What value is being generated by pushing this code in its current form? It doesn't work so nobody else is getting a chance to use it. It generates warnings that we all see and have to double-check are unrelated to something we're working on. (Emacs jumps us into your code after every pull or if we touch a public header.) Even if we're curious what you're doing, there's no sense looking at this code, but we don't have any automatic way to determine what you think works.</div>
</div></blockquote><div><br></div><div style>It is not the current workflow that must be justified, but a mandatory change in that workflow. I don't think there is any</div><div style>evidence that it increases productivity, and quite a lot that it is rather marginal on that score while increasing development</div>
<div style>costs. I do not see any effect from these kind of pushes. Does that mean my workflow is more robust, and we should force</div><div style>it on everyone else?</div><div style><br></div><div style>Code management is not just about doing what seems most logical and efficient to you, but imposing as little</div>
<div style>as possible on the developers and honestly evaluating the gains/losses to productivity of 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">
<div dir="ltr"><div class="gmail_extra">I see haphazard work-in-progress pushes as being tantamount to repository spam. And if you need a sequence of commits to implement a feature, it would be much better for them to be in a sequence that gets merged in at once, because then we can look at the series instead of trying to somehow relate individual commits scattered throughout the (mostly-linearized) history.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">If you're trying to get early feedback about portability, maybe we should figure out how to set up automated builds for stuff that's not yet in petsc-dev.</div>

</div>
</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>