Removing buggy features vs. keeping workflows - Redmine #1971
Archive from user: Erik Lindahl
For quite a few recent bugs we have ended up in this situation:
- For convenience, we have added hacks or extra command line options to enable some workflow or save time.
- These hacks suddenly mean there are half-a-dozen ways to do things (e.g. continue simulations), which leads to bugs.
- The person using the workflow doesn’t care too much, because they are not hit by the bug.
- When somebody else tries to clean it up by removing features, there are (understandable) complaints that we should not break workflows.
Most of us think it is more fun to work on performance and features
rather than stability/usability/fixing, which tends to compound the
problem so these issues stay partially broken for years (one current
example is the -deffnm feature).
This makes it extremely unthankful for the people who do try to fix
other developers’ bugs (in particular Mark) since they constantly get
complaints that features cannot be removed, but very little help with
the actual fixing.
So, for release-2017 and the future I would suggest to change the rules of that game a bit:
- It should still be perfectly OK to say that a feature is important and that it should stay, but that has to come with with an implied promise to help fix the bugs it causes.
- In that case, people who want it removed because it is buggy should hold off for a few months (or maybe even one full release).
- However, a large part of the responsibility for fixing things fall on the person(s) who wanted the feature to stay.
- When no fixing happens (which this far has been the norm), the “important workflow” argument should no longer carry any significant weight.
Mark had a good formulation during the Göttingen workshop that we (and other projects) tend to build up a technical “debt” when we have added code and features that is not as foolproof as it should be. At some point we need to pay that debt, either in terms of no longer having features that are buggy (no matter how useful a workflow might be to an expert user not hit by the bug), or by helping to fix them.
(from redmine: issue id 1971, created on 2016-05-26 by gmxdefault)
- Relations:
- relates #1117 (closed)
- relates #1292 (closed)
- relates #1323 (closed)
- relates #1500 (closed)
- relates #1998 (closed)
- relates #1354 (closed)
- relates #753 (closed)
- relates #1095 (closed)
- relates #1781 (closed)
- relates #2224 (closed)
- relates #2391 (closed)
- relates #1249 (closed)
- relates #1852 (closed)
- Changesets:
- Revision f5cb6c13 by Mark Abraham on 2018-01-11T00:41:16Z:
Announce in user log files that features are deprecated.
These are merely informational notes, not warnings or errors.
Refs #1781, #1971, #2136
Change-Id: I96e19acb0e15d3f42b0929f555b451299a2882e4
- Revision 6a334106 by Mark Abraham on 2018-01-23T16:51:22Z:
Remove topology support for implicit solvation
Refs #1500
Refs #1971
Change-Id: I75d05d52ea1d528f63f2249da62f0bcfca4274d2
- Revision 93c6b6d6 by Mark Abraham on 2018-01-23T17:08:21Z:
Remove support for implicit solvation
Mdp files with implicit-solvent = no can still be read, and formerly
valid related fields are now ignored, so that default mdp files from
previous versions of GROMACS will work. Anything else for the
implciit-solvent mdp value gives an error in grompp.
grompp can now only write a tpr file that has a false value for
ir->implicit_solvent, but can read older versions. When mdrun is
presented with an older tpr file that did such a simulation, it
refuses to run, presenting a useful error message. Such tpr files are
still useful for other purposes, so can still be read, except that the
fields specific to these methods are ignored.
grompp now ignores the topology directives for related parameters,
which means that force-field folders that are the same as, or
modifications of folders formerly supported by GROMACS still
work. However, the versions currently distributed have none of those
fields.
The group-scheme kernels have been removed, and generation
infrastructure updated so that they do generate the code that's in the
repo. However, now that the python generation scripts no longer
generate GB kernels, the dictionary ordering changes, which changes
the generated output. That output is not sensitive to the order of the
declarations or data-structure elements, so this is only a cosmetic
issue.
Documentation has been removed.
Unit tests on .mdp file handling have had to be updated.
Also removed unused enbcoul enumeration
Refs #1500
Refs #1971
Fixes #1054
Change-Id: Ib241555ff3d8e60012ba0e628ab0f9a3f91eca9e