<div dir="ltr"><div><div><div><div>Hi,<br><br></div>Good points! I think such a guide coding workflow guidelines would really be useful on a wiki.<br><br></div>I wonder, when do you propose that devs upload changes to jenkins? To what extent should we offer/suggest the use of jenkins and its infrsastructure for builds during such development?<br></div>I think it would be best if people kept unstable dev branches in their private repos until there is really a point to share and get feedback in form of review rather than just saving time to avoid building anything else but e.g. the single debug & no GPU & no MPI config used for development.<br><br><br></div>Cheers,</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Szilárd</div></div>
<br><div class="gmail_quote">On Tue, Sep 8, 2015 at 2:20 PM, Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</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">Hi,<div><br></div><div>We've had one or two discussions recently about how to manage our code development with minimal friction. Often while tackling some new or changed functionality, it becomes clear that some piece of infrastructure should change as well. The cleanup/reorganization/extension is often good to handle separately from the new functionality, so that other code can start using it immediately, and the surface area of each patch stays as small as possible. This makes it easier to reason about each change, when writing and reviewing.</div><div><br></div><div>Ideas for how to get this done:</div><div><br></div><div>Be mentally prepared to throw work away - your first experiment, your first simulation and your first draft of a paper are often horrible, and code is no different. You often don't know what you need to do until you've tried to do it and/or have the requisite general experience.</div><div><br></div><div>Make sure you have a way to run the code easily - at least so you can know immediately that what you've changed compiles and doesn't segfault.</div><div><br></div><div>Edit code with only one, small objective in mind. Commit code frequently - saying "WIP adding xyz - compiles!" is a great commit message for your local development branch. "Extended XSDE to support xcf" is also great. If you do this, you'll end up with a series of commits and each one is reasonably clear about whether it is cleanup, preparatory infrastructure changes, or new functionality. git rebase can then let you move your cleanup and infrastructure patches early in your history. Your tests will let you re-visit points in your revised history and see that things compile.</div><div><br></div><div>When you realize that stuff needs cleaning up before you can do what you want to do, stop and think about what that means for the larger objective that you have - maybe you should go do that cleanup and then re-write much of your code in that new context.</div><div><br></div><div>Otherwise, make a work-in-progress git stash/commit/branch (whatever works for you), check out an early version of this branch of your development repo and do the cleanup, test it, etc. Then cherry-pick your old work-in-progress on top of it, resolve any issues.</div><div><br></div><div>If one has failed to do any of the above, there is still the option of squashing work into a single git commit, looking for some logical sub-pieces of the work, and using <a href="http://stackoverflow.com/questions/1440050/how-to-split-last-commit-into-two-in-git" target="_blank">http://stackoverflow.com/questions/1440050/how-to-split-last-commit-into-two-in-git</a> and perhaps <a href="http://stackoverflow.com/questions/1085162/commit-only-part-of-a-file-in-git" target="_blank">http://stackoverflow.com/questions/1085162/commit-only-part-of-a-file-in-git</a> to separate things.</div><div><br></div><div>Example case: GROMACS OpenCL support</div><div><br></div><div>StreamComputing forked GROMACS release-5-0 on github (<a href="https://github.com/StreamComputing/gromacs" target="_blank">https://github.com/StreamComputing/gromacs</a>), and several of their developers worked on adding OpenCL functionality for several months. GROMACS master moved on, of course. When things were approximately complete, we decided that much of the OpenCL development history was of no interest to the GROMACS repo. I merged gromacs/master into their github branch, and made a number of cleanup patches (e.g. <a href="https://github.com/StreamComputing/gromacs/commit/2884290bada2f1245ea0c05dfd278a1356a14517" target="_blank">https://github.com/StreamComputing/gromacs/commit/2884290bada2f1245ea0c05dfd278a1356a14517</a>) with a view to ending up with the ability to separate two commits. One that didn't change GROMACS functionality, but prepared us to move away from GPU being synonymous with CUDA (<a href="https://gerrit.gromacs.org/#/c/4306/" target="_blank">https://gerrit.gromacs.org/#/c/4306/</a>) so that other CUDA development work could proceed without much impact on the OpenCL review process, and then one commit that added the new functionality (<a href="https://gerrit.gromacs.org/#/c/4314/" target="_blank">https://gerrit.gromacs.org/#/c/4314/</a>).</div><div><br></div><div>In my perfect world, from the latter commit we'd also have separated some forcerec.cpp-related cleanup, CMake support, fastgen, JIT caching and twin-range support into separate commits. The usefulness of the latter three partitions didn't become clear to me until very late in the piece - when I realized that fastgen+twin-range would remove most of the need for JIT caching, which was problematic to implement well.</div><div><br></div><div>None of this lunch is free, of course. The lesson to do one thing at a time comes hard to smart people sometimes :-)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Mark</div></font></span></div>
<br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div>