[petsc-dev] Pushing non-working code

[Matthew Knepley]

On Sat, Feb 2, 2013 at 6:00 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

>
> 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.
>

It is not the current workflow that must be justified, but a mandatory
change in that workflow. I don't think there is any
evidence that it increases productivity, and quite a lot that it is rather
marginal on that score while increasing development
costs. I do not see any effect from these kind of pushes. Does that mean my
workflow is more robust, and we should force
it on everyone else?

Code management is not just about doing what seems most logical and
efficient to you, but imposing as little
as possible on the developers and honestly evaluating the gains/losses to
productivity of changes.

   Matt


> 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.
>



-- 
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/20130203/1028703b/attachment.html>