<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2nm">'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><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" style>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" style><br></div><div class="gmail_extra" style>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>