On Sat, Feb 2, 2013 at 5:20 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Sat, Feb 2, 2013 at 4:14 PM, Matthew Knepley <knepley at gmail.com> wrote: > >> I think non-working is a misnomer here. These do not break the build. > > > They issue warnings and the code can't possibly execute correctly. Just > don't push it (or push it somewhere else) until it's been cleaned up to the > point where it's not wasting our time to review. > 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. Matt > Related: I would like to start tweaking our workflow to make petsc-dev > more consistently stable, so that more applications can work with it > instead of needing to wait for a release. Having people pushing code that > doesn't work, isn't tested, and obviously wouldn't pass review is not good > for stability. > -- 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/20130202/3aa6bc3b/attachment-0001.html>
