<div dir="ltr"><div class="gmail_extra"><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>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 class="gmail_extra"><br></div><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" style>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>