[gmx-developers] future of tabulated bonded interactions

[Szilárd Páll]

Hi,

I agree with Berk, but I'd go even further: if actions are taken as
the previous ultimatum projects, I don't think anybody can claim that
GROMACS is a community project -- not in the sense that it _serves_ a
wider community. If the goal is to turn the page flush out most legacy
code and keep only features that serve the narrow community of tightly
coupled stakeholders, one may as well just state that upfront. If
people care about the current feature set, they will likely just keep
using old versions or maybe even fork.

Cheers,
--
Szilárd


On Wed, Jun 1, 2016 at 12:23 PM, Berk Hess <hess at kth.se> wrote:
> Hi,
>
> While I agree we have a maintenance issue, this strategy will lead to all
> features the current developers don't use/don't care about to disappear at a
> high rate. There might be (or might not be) significant numbers of users in
> the world using such features. The question is what happens then. Will
> people abandon GROMACS? Keep using an old version? Or complain that some
> feature is not there? If they complain, will something happen? I suspect
> most people don't have the coding skills and GROMACS knowledge to
> contribute. Not that I see another good solution though.
> This is a point we should bring up at the telcon today.
>
> PS I do care about tabulated bondeds and a had looked at your change more
> than once, but have not had the time yet to do a thorough enough review for
> a +2.
>
> Cheers,
>
> Berk
>
>
> On 01/06/16 12:06 , Mark Abraham wrote:
>
> Hi,
>
> While working on table support for the Verlet scheme a few months ago
> (particularly, putting the tables into the .tpr for better user experience),
> I added some tests for tabulated bonded interactions and discovered that
> these have been broken in release-5-1, after we changed some command-line
> handling for improved robustness elsewhere. That's because for a long time
> the table filenames have been inferred by mdrun in a hacky way.
>
> So I've fixed them, and after two months Teemu found time to look at the
> straightforward fix + tests. After a further month, nobody else has had time
> to look. Meanwhile, it isn't worth me continuing development to support such
> a feature until I see that somebody cares about it.
>
> We cannot continue like this. If the software is too large/broken/untested
> for people to maintain, them we must make it smaller. And if we apply it to
> tabulated bondeds, then it will also apply immediately to lots of the other
> things that people say are nice to have if someone else will do the work to
> fix the known problems. Even when someone has volunteered to support the
> feature, if nobody will volunteer to review their maintenance patches, then
> the feature cannot remain in the code.
>
> After we release 2016, I will make a checklist of mdrun features, platforms,
> analysis tools, and solicit volunteers to a) maintain them, and b) review
> related code changes. If stuff doesn't have volunteers by September 1, then
> I will remove it forthwith. That goes for the group scheme and old-style
> analysis tools, too! In future, if the volunteers for a feature aren't able
> to help in practice, e.g. they say nothing at all for a month after a
> problem surfaces or a patch needs review, then they'll be removed from
> volunteer status, and if there's no replacement around, the feature goes.
>
> Your not-feeling-benevolent-today dictator,
>
> Mark
>
>
>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.