[gmx-developers] Re: 4.6.1 soon!

[Christoph Junghans]

2013/2/19 Mark Abraham <mark.j.abraham at gmail.com>:
>
>
> On Tue, Feb 19, 2013 at 5:30 PM, Christoph Junghans <junghans at votca.org>
> wrote:
>>
>> 2013/2/19 Mark Abraham <mark.j.abraham at gmail.com>:
>> >
>> >
>> > On Tue, Feb 19, 2013 at 4:02 AM, Christoph Junghans <junghans at votca.org>
>> > wrote:
>> >>
>> >> 2013/2/18 Mark Abraham <mark.j.abraham at gmail.com>:
>> >> >
>> >> >
>> >> > On Mon, Feb 18, 2013 at 8:39 PM, Christoph Junghans
>> >> > <junghans at votca.org>
>> >> > wrote:
>> >> >>
>> >> >> 2013/2/18 Berk Hess <hess at kth.se>:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I fully agree.
>> >> >> > Since OpenMM is not fully supported 6.1.12 should be removed from
>> >> >> > the
>> >> >> > manual.
>> >> >> Apropos OpenMM, currently there are some directory offsets wrong in
>> >> >> the build system, which make it practically impossible to enable the
>> >> >> OpenMM support:
>> >> >> <https://gerrit.gromacs.org/#/c/2087/>
>> >> >> A fix should go into 4.6.1. The above change set is not complete yet
>> >> >> as some CMAKE_CXX variables are missing.
>> >> I guess, we just need to enable CXX, before the compiler checks to fix
>> >> the above issue, but then we would have an openmm conditional in main
>> >> cmakelists.txt file, which is also not nice.
>> >> >
>> >> >
>> >> > I looked at that patch last week, and it seemed to me like there was
>> >> > not
>> >> > much consensus about what solution was appropriate. I thought we'd
>> >> > probably
>> >> > not reach an acceptable solution in time for 4.6.1. Thus it's not in
>> >> > the
>> >> > list of commits I plan for 4.6.1. The choice of commits and timing
>> >> > for a
>> >> > release is normally pretty arbitrary, but there has to be one or we
>> >> > never
>> >> > deliver anything!
>> >> I like to have deadlines, but that also means we have to find a
>> >> consensus in time and not just ignore things.
>> >> As far as I can see only Szilard had an opinion on that issue.
>> >
>> >
>> > 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
>> > :-)
>> To clarify, I don't ask you to fix it, I will take care of it as soon
>> as we have decided on something, I just don't want to waste my time
>> fixing it if the patch doesn't get merged in the end ;-)
>
>
> Understood :-)
>
> There's no embargo. If someone says they've fixed OpenMM to work from
> contrib, then the code will get reviewed and presumably get merged after due
> process. There just won't be Stockholm people spending significant time on
> it :-)
>
>> > 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
>> > :-)
>> >
>> >> > If fixing OpenMM to build and/or work from src/contrib is important
>> >> > to
>> >> > someone, then they're welcome to spend some time on it. Frankly,
>> >> > there's
>> >> > not
>> >> > much of value in 4.6 that will also benefit someone who needs an
>> >> > OpenMM-capable mdrun. If I needed the latter, I'd be installing a
>> >> > 4.5.x
>> >> > version of GROMACS for OpenMM and hoping for the best!
>> >> >
>> >> > I'd be perfectly happy removing it entirely from the repo. One of the
>> >> > joys
>> >> > of version control is that it is easy to revert the deletion patch.
>> >> I haven't heard any complains on the user's list, so I guess removing
>> >> it would be the easiest, quickest and cleanest solution, but Szilard
>> >> had the opposite opinion. In the current state nobody will realize
>> >> when md_openmm.c and normal md.c get out of sync as it is hard to
>> >> build in the first place,  it is just a matter of time until openmm
>> >> support gets completely broken.
>> >
>> >
>> > 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.
>> >
>> > 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.
>> The only reason why I am pushing for a fix is that, right now, one
>> cold get the impression that uncommenting a single line in
>> src/contrib/CMakeLists.txt would be enough to build OpenMM, which is
>> not the case.
>>
>> I guess we have 4 solutions:
>> a.) change the comment in src/contrib/CMakeLists.txt
>> b.) fix it for 4.6.1 or 4.6.2 (90% done in
>> <https://gerrit.gromacs.org/#/c/2087/>)
b.) is done: <https://gerrit.gromacs.org/#/c/2087/6>
and one doesn't even need to uncomment the option -DGMX_OPENMM=ON
works either way.

>> c.) remove OpenMM reference from everywhere, but src/contrib to make
>> it 100% contrib (will take me 5 mins to create a patch)
>> d.) feature branch (+c.) in release-4-6 branch)
>
>
> I'm happy with:
>
> a) and walk away
> a) and do minimal work on b) for 4.6.2 (4.6.1 freeze is already past; I'd
> have shipped a tarball whenever the code gets reviewed already :-))
> b) for 4.6.2
> c) if it's possible to do that, sure (then, ideally, b) for 4.6.2)
>
> IMO there's only cosmetic value in d.
>
> Mark
>
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.



--
Christoph Junghans
Web: http://www.compphys.de