On Sat, Feb 2, 2013 at 4:38 PM, Matthew Knepley <knepley at gmail.com> wrote:
> I would love it if people never pushed code with any bugs. This is > possible, just not efficient. All changes to > workflow should be evaluated on this basis. For this particular change, > > 1) It does not break the build > > 2) Its a new feature, so does not break tests except the ones its > supposed to > > I do think warnings are annoying and people should endeavor to push code > with no > warnings, but making this a requirement takes away flexibility while > providing nothing > I can see except lack of Jed Annoyance. The claim that you are code > reviewing this > push is false on its face. > > I think this play into a larger issue. Does the increased process burden > you are recommending > actually bring increased productivity. That the answer is yes is not at > all clear. It is easy to make > the mistake that because something sounds good and "right" that you should > do it. This dooms > most CS projects. > 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. 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130202/5594fb13/attachment.html>
