[gmx-developers] Critical bug communication policy

[Mark Abraham]

On 6/06/2012 10:13 AM, Roland Schulz wrote:
> Hi,
>
> 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 scanned the git log and didn't see any critical issues that seemed 
likely to affect more than a handful of users.

Once upon a time there was gmx-announce mailing list, but I've never 
seen it used.

> 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.

I'm all for reasonably frequent (e.g. 3-6 months, or sooner if there's a 
major issue fixed) and as our automated testing and code review gathers 
steam this will be easier and more reliable than ever.

>
> 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)?

Tough one... fftpack being the default means there could be a bunch of 
users affected, but often they won't know they are using fftpack and 
mostly they won't know what their Fourier grid size was if they used 
fourierspacing. I'd let it pass quietly.

Mark