Hi,<div><br></div><div>A community by definition has to have mutual give and take, and communication. A member of the community who wants to use GROMACS in their scientific work, maybe modify it, and cite suitable past work is most welcome to do that - most people will only do that - but they can't also have much of a say in how the code will change unless that overlaps with a lot of other people's needs. Almost everybody needs the core of mdrun faster, and everybody needs core preparation and analysis tools to work well, but this cannot happen while simultaneously paying the technical debt for past development practices. It's inexcusable that we have a user on gmx-users right now who gets a segfault with gmx trjconv -dump on the first frame of their trajectory. </div><div><br></div><div>We should solicit widely for help with constructing tests and documentation, but if people don't opt in, then they *have* opted out of the active community.</div><div><br></div><div>So if e.g. votca chooses not to help with tabulated bondeds testing now, then later decides they need OpenCL support, and discover that tabulated bondeds were broken in 5.1 and then dropped for lack of interest, then they have reason to work within the community to restore it. In the meantime, the task parallelism people didn't have to consider how to refactor and test bonded kernels that nobody needed<span style="font-size:13px">, yet. If nobody is found who wants to help in the meantime, then the community has literally voted not to support the feature. And that's OK!</span></div><div><br></div><div>Mark<br><br><div class="gmail_quote"><div dir="ltr">On Wed, 1 Jun 2016 16:21 Szilárd Páll <<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I agree with Berk, but I'd go even further: if actions are taken as<br>
the previous ultimatum projects, I don't think anybody can claim that<br>
GROMACS is a community project -- not in the sense that it _serves_ a<br>
wider community. If the goal is to turn the page flush out most legacy<br>
code and keep only features that serve the narrow community of tightly<br>
coupled stakeholders, one may as well just state that upfront. If<br>
people care about the current feature set, they will likely just keep<br>
using old versions or maybe even fork.<br>
<br>
Cheers,<br>
--<br>
Szilárd<br>
<br>
<br>
On Wed, Jun 1, 2016 at 12:23 PM, Berk Hess <<a href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>> wrote:<br>
> Hi,<br>
><br>
> While I agree we have a maintenance issue, this strategy will lead to all<br>
> features the current developers don't use/don't care about to disappear at a<br>
> high rate. There might be (or might not be) significant numbers of users in<br>
> the world using such features. The question is what happens then. Will<br>
> people abandon GROMACS? Keep using an old version? Or complain that some<br>
> feature is not there? If they complain, will something happen? I suspect<br>
> most people don't have the coding skills and GROMACS knowledge to<br>
> contribute. Not that I see another good solution though.<br>
> This is a point we should bring up at the telcon today.<br>
><br>
> PS I do care about tabulated bondeds and a had looked at your change more<br>
> than once, but have not had the time yet to do a thorough enough review for<br>
> a +2.<br>
><br>
> Cheers,<br>
><br>
> Berk<br>
><br>
><br>
> On 01/06/16 12:06 , Mark Abraham wrote:<br>
><br>
> Hi,<br>
><br>
> While working on table support for the Verlet scheme a few months ago<br>
> (particularly, putting the tables into the .tpr for better user experience),<br>
> I added some tests for tabulated bonded interactions and discovered that<br>
> these have been broken in release-5-1, after we changed some command-line<br>
> handling for improved robustness elsewhere. That's because for a long time<br>
> the table filenames have been inferred by mdrun in a hacky way.<br>
><br>
> So I've fixed them, and after two months Teemu found time to look at the<br>
> straightforward fix + tests. After a further month, nobody else has had time<br>
> to look. Meanwhile, it isn't worth me continuing development to support such<br>
> a feature until I see that somebody cares about it.<br>
><br>
> We cannot continue like this. If the software is too large/broken/untested<br>
> for people to maintain, them we must make it smaller. And if we apply it to<br>
> tabulated bondeds, then it will also apply immediately to lots of the other<br>
> things that people say are nice to have if someone else will do the work to<br>
> fix the known problems. Even when someone has volunteered to support the<br>
> feature, if nobody will volunteer to review their maintenance patches, then<br>
> the feature cannot remain in the code.<br>
><br>
> After we release 2016, I will make a checklist of mdrun features, platforms,<br>
> analysis tools, and solicit volunteers to a) maintain them, and b) review<br>
> related code changes. If stuff doesn't have volunteers by September 1, then<br>
> I will remove it forthwith. That goes for the group scheme and old-style<br>
> analysis tools, too! In future, if the volunteers for a feature aren't able<br>
> to help in practice, e.g. they say nothing at all for a month after a<br>
> problem surfaces or a patch needs review, then they'll be removed from<br>
> volunteer status, and if there's no replacement around, the feature goes.<br>
><br>
> Your not-feeling-benevolent-today dictator,<br>
><br>
> Mark<br>
><br>
><br>
><br>
><br>
> --<br>
> Gromacs Developers mailing list<br>
><br>
> * Please search the archive at<br>
> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before<br>
> posting!<br>
><br>
> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
><br>
> * For (un)subscribe requests visit<br>
> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or<br>
> send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div></div>