[gmx-developers] Re: 4.6.1 soon!

[Mark Abraham]

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/>)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130219/1f76b432/attachment.html>