<br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 5:30 PM, Christoph Junghans <span dir="ltr">&lt;<a href="mailto:junghans@votca.org" target="_blank">junghans@votca.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2013/2/19 Mark Abraham &lt;<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>&gt;:<br>
<div><div class="h5">&gt;<br>
&gt;<br>
&gt; On Tue, Feb 19, 2013 at 4:02 AM, Christoph Junghans &lt;<a href="mailto:junghans@votca.org">junghans@votca.org</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 2013/2/18 Mark Abraham &lt;<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>&gt;:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Mon, Feb 18, 2013 at 8:39 PM, Christoph Junghans &lt;<a href="mailto:junghans@votca.org">junghans@votca.org</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; 2013/2/18 Berk Hess &lt;<a href="mailto:hess@kth.se">hess@kth.se</a>&gt;:<br>
&gt;&gt; &gt;&gt; &gt; Hi,<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; I fully agree.<br>
&gt;&gt; &gt;&gt; &gt; Since OpenMM is not fully supported 6.1.12 should be removed from the<br>
&gt;&gt; &gt;&gt; &gt; manual.<br>
&gt;&gt; &gt;&gt; Apropos OpenMM, currently there are some directory offsets wrong in<br>
&gt;&gt; &gt;&gt; the build system, which make it practically impossible to enable the<br>
&gt;&gt; &gt;&gt; OpenMM support:<br>
&gt;&gt; &gt;&gt; &lt;<a href="https://gerrit.gromacs.org/#/c/2087/" target="_blank">https://gerrit.gromacs.org/#/c/2087/</a>&gt;<br>
&gt;&gt; &gt;&gt; A fix should go into 4.6.1. The above change set is not complete yet<br>
&gt;&gt; &gt;&gt; as some CMAKE_CXX variables are missing.<br>
&gt;&gt; I guess, we just need to enable CXX, before the compiler checks to fix<br>
&gt;&gt; the above issue, but then we would have an openmm conditional in main<br>
&gt;&gt; cmakelists.txt file, which is also not nice.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I looked at that patch last week, and it seemed to me like there was not<br>
&gt;&gt; &gt; much consensus about what solution was appropriate. I thought we&#39;d<br>
&gt;&gt; &gt; probably<br>
&gt;&gt; &gt; not reach an acceptable solution in time for 4.6.1. Thus it&#39;s not in the<br>
&gt;&gt; &gt; list of commits I plan for 4.6.1. The choice of commits and timing for a<br>
&gt;&gt; &gt; release is normally pretty arbitrary, but there has to be one or we<br>
&gt;&gt; &gt; never<br>
&gt;&gt; &gt; deliver anything!<br>
&gt;&gt; I like to have deadlines, but that also means we have to find a<br>
&gt;&gt; consensus in time and not just ignore things.<br>
&gt;&gt; As far as I can see only Szilard had an opinion on that issue.<br>
&gt;<br>
&gt;<br>
&gt; When resources are finite, things get deferred. I&#39;m our only full-time<br>
&gt; resource on this project. Everybody else is some degree of volunteer. It&#39;s<br>
&gt; great that we have such willing, capable and dedicated volunteers, but we<br>
&gt; all have to prioritise our time. I know I could keep two clones of me busy<br>
&gt; :-)<br>
</div></div>To clarify, I don&#39;t ask you to fix it, I will take care of it as soon<br>
as we have decided on something, I just don&#39;t want to waste my time<br>
fixing it if the patch doesn&#39;t get merged in the end ;-)<br></blockquote><div><br></div><div>Understood :-)</div><div><br></div><div>There&#39;s no embargo. If someone says they&#39;ve fixed OpenMM to work from contrib, then the code will get reviewed and presumably get merged after due process. There just won&#39;t be Stockholm people spending significant time on it :-)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
&gt; In the case of things in contrib, that deferral might in practice be<br>
&gt; infinite. That&#39;s life. There&#39;s 170 open Redmine issues needing attention :-)<br>
&gt;<br>
&gt;&gt; &gt; If fixing OpenMM to build and/or work from src/contrib is important to<br>
&gt;&gt; &gt; someone, then they&#39;re welcome to spend some time on it. Frankly, there&#39;s<br>
&gt;&gt; &gt; not<br>
&gt;&gt; &gt; much of value in 4.6 that will also benefit someone who needs an<br>
&gt;&gt; &gt; OpenMM-capable mdrun. If I needed the latter, I&#39;d be installing a 4.5.x<br>
&gt;&gt; &gt; version of GROMACS for OpenMM and hoping for the best!<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I&#39;d be perfectly happy removing it entirely from the repo. One of the<br>
&gt;&gt; &gt; joys<br>
&gt;&gt; &gt; of version control is that it is easy to revert the deletion patch.<br>
&gt;&gt; I haven&#39;t heard any complains on the user&#39;s list, so I guess removing<br>
&gt;&gt; it would be the easiest, quickest and cleanest solution, but Szilard<br>
&gt;&gt; had the opposite opinion. In the current state nobody will realize<br>
&gt;&gt; when md_openmm.c and normal md.c get out of sync as it is hard to<br>
&gt;&gt; build in the first place,  it is just a matter of time until openmm<br>
&gt;&gt; support gets completely broken.<br>
&gt;<br>
&gt;<br>
&gt; Yep. It&#39;s in contrib so it&#39;s clear we&#39;re not maintaining it. There&#39;s<br>
&gt; probably other stuff that will join it later in the year. Ideally, stuff in<br>
&gt; contrib would work, rather than be a dumping ground, but that requires<br>
&gt; maintenance and testing and we&#39;re not prepared to do that for things we&#39;ve<br>
&gt; put in contrib. Two months elapsed after people in Stockholm decided they<br>
&gt; didn&#39;t want to maintain it, so I took the initiative to move it to where<br>
&gt; that decision was clear to the wider team. Another month has passed. If<br>
&gt; nobody wants to make it work or maintain it there, then it will quietly die.<br>
&gt;<br>
&gt; An alternative would be to create a &quot;feature&quot; branch that labels the &quot;last<br>
&gt; believed good&quot; version of code before we decide to stop supporting it &amp;<br>
&gt; remove its code. That&#39;s just going to be a label on a commit. The same<br>
&gt; purpose is served by looking at the parent of the commit before a feature&#39;s<br>
&gt; code was moved to contrib.<br>
</div></div>The only reason why I am pushing for a fix is that, right now, one<br>
cold get the impression that uncommenting a single line in<br>
src/contrib/CMakeLists.txt would be enough to build OpenMM, which is<br>
not the case.<br>
<br>
I guess we have 4 solutions:<br>
a.) change the comment in src/contrib/CMakeLists.txt<br>
b.) fix it for 4.6.1 or 4.6.2 (90% done in<br>
&lt;<a href="https://gerrit.gromacs.org/#/c/2087/" target="_blank">https://gerrit.gromacs.org/#/c/2087/</a>&gt;)<br>
c.) remove OpenMM reference from everywhere, but src/contrib to make<br>
it 100% contrib (will take me 5 mins to create a patch)<br>
d.) feature branch (+c.) in release-4-6 branch)<br></blockquote><div><br></div><div>I&#39;m happy with:</div><div><br></div><div>a) and walk away</div><div>a) and do minimal work on b) for 4.6.2 (4.6.1 freeze is already past; I&#39;d have shipped a tarball whenever the code gets reviewed already :-))</div>
<div>b) for 4.6.2</div><div>c) if it&#39;s possible to do that, sure (then, ideally, b) for 4.6.2)</div><div><br></div><div>IMO there&#39;s only cosmetic value in d.</div><div><br></div><div>Mark</div><div><br></div></div>