[petsc-dev] Pushing non-working code

[Jed Brown]

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.


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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130202/2f1c0eb8/attachment.html>