[gmx-developers] upcoming point releases; also updates to branch statuses

Mark Abraham mark.j.abraham at gmail.com
Wed Oct 21 16:57:28 CEST 2015


Hi,

I would like to get a 5.1.1 out the door soon. There's a few minor issues
needing attention at
https://gerrit.gromacs.org/#/q/status:open+project:gromacs+branch:release-5-1,
and I would like Berk and Michael to consider my merge at
https://gerrit.gromacs.org/#/c/5210/ carefully.

That merge is a good illustration of why we need to stop fixing things in
old branches at some point. The problem arose so long ago that people were
unsure what the fix was, and once we agreed on a fix and submitted it,
understandably people go off and think about more interesting things. But
in the more recent past, we did some cleanup in master branch before
release-5-1 branch was forked, and the lifetime of managing a bug fix
extends until all relevant active development branches incorporate it... On
occasions, we have definitely inadvertently re-introduced old behaviours
when people didn't remember the full context when coding and reviewing, and
this is a direct cost of fixing bugs in old branches.

Mark

On Mon, Oct 5, 2015 at 10:44 PM Mark Abraham <mark.j.abraham at gmail.com>
wrote:

> Hi,
>
> It's time for some more releases. I'll do 5.0.7 later this week, and 5.1.1
> shortly after.
>
> release-4-6 is now closed (Michael has an outstanding patch, but we can
> apply its fix elsewhere if suitable). I think we should default to blocking
> uploads to closed branches, unless there's a reason to permit it. I'll look
> into doing that. Then I'll archive the Jenkins configurations somewhere,
> and remove the jobs.
>
> release-5-0 is now only open for serious scientific correctness fixes,
> e.g. mdrun or some analysis tool is wrong. There will be a future release
> only if we judge it is clearly useful
>
> release-5-1 is open for general fixes of things that don't quite do what
> we meant them to do. Such changes must not change correct functionality,
> and change as few things as necessary to do the job reasonably. Invasive or
> risky fixes should go on master branch. There will be future releases
> roughly every 2 months.
>
> master is open for general business, including cleanup, features, fixes.
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20151021/b5041569/attachment.html>


More information about the gromacs.org_gmx-developers mailing list