<br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 4:02 AM, Christoph Junghans <span dir="ltr"><<a href="mailto:junghans@votca.org" target="_blank">junghans@votca.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2013/2/18 Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>>:<br>
<div class="im">><br>
><br>
> On Mon, Feb 18, 2013 at 8:39 PM, Christoph Junghans <<a href="mailto:junghans@votca.org">junghans@votca.org</a>><br>
> wrote:<br>
>><br>
>> 2013/2/18 Berk Hess <<a href="mailto:hess@kth.se">hess@kth.se</a>>:<br>
>> > Hi,<br>
>> ><br>
>> > I fully agree.<br>
>> > Since OpenMM is not fully supported 6.1.12 should be removed from the<br>
>> > manual.<br>
>> Apropos OpenMM, currently there are some directory offsets wrong in<br>
>> the build system, which make it practically impossible to enable the<br>
>> OpenMM support:<br>
>> <<a href="https://gerrit.gromacs.org/#/c/2087/" target="_blank">https://gerrit.gromacs.org/#/c/2087/</a>><br>
>> A fix should go into 4.6.1. The above change set is not complete yet<br>
>> as some CMAKE_CXX variables are missing.<br>
</div>I guess, we just need to enable CXX, before the compiler checks to fix<br>
the above issue, but then we would have an openmm conditional in main<br>
cmakelists.txt file, which is also not nice.<br>
<div class="im">><br>
><br>
> I looked at that patch last week, and it seemed to me like there was not<br>
> much consensus about what solution was appropriate. I thought we'd probably<br>
> not reach an acceptable solution in time for 4.6.1. Thus it's not in the<br>
> list of commits I plan for 4.6.1. The choice of commits and timing for a<br>
> release is normally pretty arbitrary, but there has to be one or we never<br>
> deliver anything!<br>
</div>I like to have deadlines, but that also means we have to find a<br>
consensus in time and not just ignore things.<br>
As far as I can see only Szilard had an opinion on that issue.<br></blockquote><div><br></div><div>When resources are finite, things get deferred. I'm our only full-time resource on this project. Everybody else is some degree of volunteer. It's great that we have such willing, capable and dedicated volunteers, but we all have to prioritise our time. I know I could keep two clones of me busy :-)</div>
<div><br></div><div>In the case of things in contrib, that deferral might in practice be infinite. That's life. There's 170 open Redmine issues needing attention :-) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> If fixing OpenMM to build and/or work from src/contrib is important to<br>
> someone, then they're welcome to spend some time on it. Frankly, there's not<br>
> much of value in 4.6 that will also benefit someone who needs an<br>
> OpenMM-capable mdrun. If I needed the latter, I'd be installing a 4.5.x<br>
> version of GROMACS for OpenMM and hoping for the best!<br>
><br>
> I'd be perfectly happy removing it entirely from the repo. One of the joys<br>
> of version control is that it is easy to revert the deletion patch.<br>
</div>I haven't heard any complains on the user's list, so I guess removing<br>
it would be the easiest, quickest and cleanest solution, but Szilard<br>
had the opposite opinion. In the current state nobody will realize<br>
when md_openmm.c and normal md.c get out of sync as it is hard to<br>
build in the first place, it is just a matter of time until openmm<br>
support gets completely broken.<br></blockquote><div><br></div><div>Yep. It's in contrib so it's clear we're not maintaining it. There's probably other stuff that will join it later in the year. Ideally, stuff in contrib would work, rather than be a dumping ground, but that requires maintenance and testing and we're not prepared to do that for things we've put in contrib. Two months elapsed after people in Stockholm decided they didn't want to maintain it, so I took the initiative to move it to where that decision was clear to the wider team. Another month has passed. If nobody wants to make it work or maintain it there, then it will quietly die.</div>
<div><br></div><div>An alternative would be to create a "feature" branch that labels the "last believed good" version of code before we decide to stop supporting it & remove its code. That's just going to be a label on a commit. The same purpose is served by looking at the parent of the commit before a feature's code was moved to contrib.</div>
<div><br></div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Christoph<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Mark<br>
><br>
>><br>
>> Cheers,<br>
>><br>
>> Christoph<br>
>><br>
>><br>
>> > Are there any other issues with the manual you know of?<br>
>> ><br>
>> > Cheers,<br>
>> ><br>
>> > Berk<br>
>> ><br>
>> ><br>
>> > On 02/18/2013 02:18 PM, Justin Lemkul wrote:<br>
>> >><br>
>> >><br>
>> >> Hi All,<br>
>> >><br>
>> >> I'm assuming fixes to the manual are being considered separately then?<br>
>> >> To<br>
>> >> me, we really shouldn't release 4.6.1 unless we have a corresponding<br>
>> >> manual<br>
>> >> out at least within 24 hr of the code being made public. In my mind,<br>
>> >> released code necessitates a definitive manual, and there have been<br>
>> >> questions on the user list related to the manual. There are still some<br>
>> >> glaring inaccuracies and outdated information, mostly in section 6.12<br>
>> >> related to GPU usage (basically it needs to be scrapped, since OpenMM<br>
>> >> isn't<br>
>> >> even fully supported any more) and Appendix A. My patch related to<br>
>> >> environment variables (<a href="https://gerrit.gromacs.org/#/c/2055/" target="_blank">https://gerrit.gromacs.org/#/c/2055/</a>) is<br>
>> >> basically<br>
>> >> done since Szilard finished off the last few items, but hasn't even<br>
>> >> been<br>
>> >> reviewed.<br>
>> >><br>
>> >> -Justin<br>
>> >><br>
>> >> On 2/18/13 8:07 AM, Mark Abraham wrote:<br>
>> >>><br>
>> >>> Hi GROMACS developers,<br>
>> >>><br>
>> >>> There's a release branch constructed, containing a number of minor<br>
>> >>> fixes,<br>
>> >>> documentation updates and a few remaining fixes of critical issues.<br>
>> >>> Below<br>
>> >>> is a<br>
>> >>> list of commits that are ancestors of the 4.6.1 release patch - please<br>
>> >>> review<br>
>> >>> things that you know about!<br>
>> >>><br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I60998e3b,n,z" target="_blank">https://gerrit.gromacs.org/#q,I60998e3b,n,z</a> New patch release 4.6.1<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I9a551260,n,z" target="_blank">https://gerrit.gromacs.org/#q,I9a551260,n,z</a> Update outdated admin<br>
>> >>> things<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,Iba5b4c66,n,z" target="_blank">https://gerrit.gromacs.org/#q,Iba5b4c66,n,z</a> Fixes for install guide<br>
>> >>> page.<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,Ia0a571d2,n,z" target="_blank">https://gerrit.gromacs.org/#q,Ia0a571d2,n,z</a> Updated install guide<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I33495d57,n,z" target="_blank">https://gerrit.gromacs.org/#q,I33495d57,n,z</a> Uncrustified code changes<br>
>> >>> since 4.6<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,If96fd044,n,z" target="_blank">https://gerrit.gromacs.org/#q,If96fd044,n,z</a> Bump shared object version<br>
>> >>> to<br>
>> >>> 8<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I79a06b20,n,z" target="_blank">https://gerrit.gromacs.org/#q,I79a06b20,n,z</a> fixed issues with FEP<br>
>> >>> soft-core and<br>
>> >>> cut-off's<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,Ib90ac4e5,n,z" target="_blank">https://gerrit.gromacs.org/#q,Ib90ac4e5,n,z</a> Merge release-4-5-patches<br>
>> >>> into<br>
>> >>> release-4-6<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I146592c3,n,z" target="_blank">https://gerrit.gromacs.org/#q,I146592c3,n,z</a> fixed GPU particle<br>
>> >>> gridding<br>
>> >>> performance issue<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I268bbf65,n,z" target="_blank">https://gerrit.gromacs.org/#q,I268bbf65,n,z</a> Made g_tune_pme work with<br>
>> >>> 4.6<br>
>> >>> if<br>
>> >>> user sets "-p" command line option<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I79fd46e1,n,z" target="_blank">https://gerrit.gromacs.org/#q,I79fd46e1,n,z</a> Fix CMake namespace<br>
>> >>> pollution<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,I3c37844c,n,z" target="_blank">https://gerrit.gromacs.org/#q,I3c37844c,n,z</a> Issue errors/warnings for<br>
>> >>> ICC<br>
>> >>> before<br>
>> >>> 12.0.0<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,Ia6157db8,n,z" target="_blank">https://gerrit.gromacs.org/#q,Ia6157db8,n,z</a> bugfix for md-vv +<br>
>> >>> nose-hoover +<br>
>> >>> (nstcalcenergy > nsttcouple)<br>
>> >>> <a href="https://gerrit.gromacs.org/#q,Ia071c6a1,n,z" target="_blank">https://gerrit.gromacs.org/#q,Ia071c6a1,n,z</a> Use explicit kernel<br>
>> >>> pointer<br>
>> >>> typecasts<br>
>> >>><br>
>> >>> Mark<br>
>> >>><br>
>> >>> On Tue, Feb 12, 2013 at 9:15 PM, Mark Abraham<br>
>> >>> <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a><br>
>> >>> <mailto:<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>>> wrote:<br>
>> >>><br>
>> >>> Hi GROMACS developers,<br>
>> >>><br>
>> >>> We've made a number of bug fixes to 4.6, and it's time we got<br>
>> >>> those<br>
>> >>> out to<br>
>> >>> the world in 4.6.1. There's a few bits and pieces still sitting in<br>
>> >>> gerrit,<br>
>> >>> so please see what you can get done. I'll plan to construct a<br>
>> >>> release<br>
>> >>> branch<br>
>> >>> on Friday and release Monday Feb 17.<br>
>> >>><br>
>> >>> Cheers,<br>
>> >>><br>
>> >>> Mark<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >><br>
>> ><br>
>> > --<br>
>> > gmx-developers mailing list<br>
>> > <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
>> > <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
>> > Please don't post (un)subscribe requests to the list. Use the www<br>
>> > interface<br>
>> > or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
>><br>
>><br>
>><br>
>> --<br>
>> Christoph Junghans<br>
>> Web: <a href="http://www.compphys.de" target="_blank">http://www.compphys.de</a><br>
>> --<br>
>> gmx-developers mailing list<br>
>> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
>> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
>> Please don't post (un)subscribe requests to the list. Use the<br>
>> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
><br>
><br>
><br>
> --<br>
> gmx-developers mailing list<br>
> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br>
> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
--<br>
Christoph Junghans<br>
Web: <a href="http://www.compphys.de" target="_blank">http://www.compphys.de</a><br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
</div></div></blockquote></div><br>