[gmx-developers] bug in 3.2.x not fixed in 3.3.1
hessb at mpip-mainz.mpg.de
hessb at mpip-mainz.mpg.de
Sat May 9 09:24:24 CEST 2009
> David Mobley wrote:
>> Berk,
>>
>>> The bug is still in 4.0.4.
>>>
>>> I would consider it bad practice to use a tpr file with a static
>>> box (no pressure coupling) and a rerun trr file with a different
>>> sized box for mdrun -rerun.
>>> Note that rerunning with a dynamic box would work fine.
>>
>> It is sort of bad practice, I suppose, BUT also the documented (if I
>> remember correctly) behavior of mdrun -rerun was to use box info from
>> the trr file; the gro file was supposed to be basically ignored.
>>
>>> But anyhow, I fixed the bug for 4.0.5 and cvs head.
>>
>> OK. Is there some reason why this was fixed once but never included in
>> the main gromacs releases? It is rather frustrating to go through the
>> process of submitting a bugzilla and helping to get the bug fixed only
>> to have the same bug come back and get me in a later version of
>> gromacs. Is there a way this can be avoided in the future?
>>
> By being somewhat more alert from both developer side and user side.
> Apparently I made a patch, which you acknowledged worked. Then someone
> (could well have been me too) closed the bug without any further
> comments. In hindsight this is bad from the developer side.
>
> I propose that whoever closes a bug in the future should comment it such
> that it is clear what has been done. There is also a role for the
> bug-reporter, since he/she get notified when a bug is closed as well, so
> this person could also demand an explanation.
>
> Maybe the bugzilla settings can be changed such that commenting is
> enforced?
I don't know if commenting is the issue here.
A bug should simply never be resolved to status "fixed"
when a patch has not been committed to at least the head branch.
Berk
More information about the gromacs.org_gmx-developers
mailing list