[gmx-developers] future of tabulated bonded interactions

[Erik Lindahl]

Hi,

Nobody has any problem with 

- old features that just work
- old features that are horrible-but-well-documented hacks, 
- old features that constantly break, but there is somebody who steps up and fixes bugs
- old features that are only used by a single group and no developer, but that group is super-helpful when it comes to help testing it


As Mark says, the problem are in the features that are horribly-broken, (often) undocumented, nobody steps up to fix them, and even when some developer *does* spend time on it, there is nobody who bothers testing it.


That is pretty much my definition of “don’t care”, rather than “care” about a feature. I find it somewhat unlikely that those users would not have time to spend 5 minutes helping test something, but they would want to spend the work on maintain a completely independent version of the code ;-)

Cheers,

Erik 



> On 01 Jun 2016, at 16:21, Szilárd Páll <pall.szilard at gmail.com> wrote:
> 
> 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.
> -- 
> 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.