[gmx-developers] Critical bug communication policy

Roland Schulz roland at utk.edu
Wed Jun 6 02:13:02 CEST 2012


how should we communicate critical bugs to the users? The definition I use
in this email for a critical bug, is one which causes wrong results without
crashes, errors, or obvious wrong results (like nan) which would alert the
user to a possible error. From those fixed by me for 4.5 I think
http://redmine.gromacs.org/issues/946  qualifies. Do we have other critical
bugs fixed in release-4-5-patches since 4.5.5?

I think ideally we would release bugfix releases frequently and would
include the list of critical bugs in the release announcement. I would
think that with Jenkins most of the testing is automatized so that the
release process becomes little work and could even be fully automatized. I
would think this should enable us to release frequently. Currently the last
release is 8.5 months old and we have 119 commits since then in
release-4-5-patches. I would be willing to help with any work required to
make a 4.5.6 release.

If we don't want to release frequently (in general or before 4.6.) I would
think we should announce critical bugs to gmx-users. Should I write an
email to gmx-users describing 946 (including that only fftpack is effected
and only multiples of 12)?


ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20120605/62504380/attachment.html>

More information about the gromacs.org_gmx-developers mailing list