[petsc-dev] Pushing non-working code

[Jed Brown]

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>