[petsc-dev] Pushing non-working code
Matthew Knepley
knepley at gmail.com
Sun Feb 3 11:11:15 CST 2013
On Sun, Feb 3, 2013 at 12:09 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Sun, Feb 3, 2013 at 9:58 AM, Matthew Knepley <knepley at gmail.com> wrote:
>
>> 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.
>>
>
> Or you see a positive effect because we fix your bugs. ;-D
>
> Coherent development improves incremental readability, which encourages
> code review and comprehension of bugs (questions like when was it
> introduced and what is affected). Code review improves up-front quality,
> but also maintainability.
>
>
>> 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.
>>
>
> Can you quantify your productivity gains that come from pushing
> checkpoints instead of waiting for a semantically meaningful point to merge
> and push?
>
I can quantify the losses from the changed you propose, which is all I need
to do. There are no "gains" from a baseline. This is
a point I have made multiple times. Changes must be justified.
Matt
--
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/93919a2b/attachment.html>
More information about the petsc-dev
mailing list