<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 2, 2013 at 5:40 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Sat, Feb 2, 2013 at 5:17 PM, Hong Zhang <span dir="ltr"><<a href="mailto:hzhang@mcs.anl.gov" target="_blank">hzhang@mcs.anl.gov</a>></span> wrote:<br>

</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>'petsc-dev' means 'dev', that a developer should be able to push on-going work<br>

after he/she does local tests and is willing to fix the warning/bug as soon as<br>
the problems appear. Personally, I am unable to write a bug/waring free code,<br>
not matter how much effort and time to put into it.</div></blockquote></div></div><br>There is a difference between</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">If you wait to push, then the patch series is coherent in the history, and there is one merge commit explaining what was merged.</div></div>
</blockquote></div><br></div>