[petsc-dev] Pushing non-working code

[Matthew Knepley]

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

> The other issue is that we work with applications that need to be able to
> rely on their PETSc being stable. If we can provide a 'dev' that is
> relatively stable, we can rapidly deliver new features, which encourages
> them to work more closely with us. If 'dev' is volatile, they will only use
> releases, in which case we have added close to a year of latency. I think
> that's bad.
>

Again, you misuse words when it is convenient for you. This is dishonest
argument.

"Stable" for applications means that the behavior of the application will
not change. This is
definitely true for your example, so characterization as "unstable" is
plainly wrong.

   Matt


> On Sat, Feb 2, 2013 at 5:40 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>>
>> On Sat, Feb 2, 2013 at 5:17 PM, Hong Zhang <hzhang at mcs.anl.gov> wrote:
>>
>>> 'petsc-dev' means 'dev', that a developer should be able to push
>>> on-going work
>>> after he/she does local tests and is willing to fix the warning/bug as
>>> soon as
>>> the problems appear. Personally, I am unable to write a bug/waring free
>>> code,
>>> not matter how much effort and time to put into it.
>>>
>>
>> There is a difference between
>>
>> 1. Pushing code that you believe to work, preferably with tests that show
>> that it works in at least some case. This code is meaningful for other
>> people to look at. In a project with strict quality control, this code
>> would not be merged until other people have had a chance to look at it.
>>
>> 2. Pushing code as a sort of personal checkpoint that really only asserts
>> that it compiles (perhaps with warnings). This is useless to push because
>> it causes other people to step over your dead code and quick-fix your
>> warnings. Worse, it confuses the history so that we can no longer look at
>> the sequence of patches that implemented a new feature.
>>
>> If you wait to push, then the patch series is coherent in the history,
>> and there is one merge commit explaining what was merged.
>>
>
>


-- 
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/a435393f/attachment.html>