Tentative high-level plans for 7.10.1

[Nicolas Trangez]

On Mon, 2014-10-06 at 11:38 +0200, Johan Tibell wrote:
> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
> wrote:
> 
> > On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at utwente.nl wrote:
> > > The danger, of course, is that people aren't very enthusiastic about
> > > bug-fixing older versions of a compiler, but for
> > > language/compiler-uptake, this might actually be a Better Way.
> >
> > Maybe some of the commercial GHC users might be interested in donating
> > the manpower to maintain older GHC versions. It's mostly a
> > time-consuming QA & auditing process to maintain old GHCs.
> >
> 
> What can we do to make that process cheaper? In particular, which are the
> manual steps in making a new GHC release today?
> 
> In the long run back porting bugfixes is the route successful OSS projects
> take. Once people have written large enough Haskell programs they will stop
> jumping onto the newer version all the time and will demand backports of
> bug fixes. This is already happening to some extent in cabal (as cabal is
> tied to a ghc release which means we need to backport changes sometimes.)

Quick note/experience report:

In my experience maintaining a project which has several older/supported
'production' versions, using backports is counter-productive, and we
decided to manage things the other way around (which is fairly easy to
do thanks to git and git-imerge):

Instead of fixing things in the latest version of the product, we fix
things in the *oldest* version of the product which should contain the
fix (or feature, whatever). Then we regularly forward-merge version
branches into the next version (especially when a release is made).

So, if 1.4.x, 1.5.x, 1.6.x and 1.7.x are 'supported' versions, and some
bug is found in 1.6.2, but turns out to be introduced in 1.5.1, we fix
the bug in the 1.5 branch.

Then, if the bugfix is important enough, we merge 1.4 in 1.5 (which can
be a no-op), 1.5 in 1.6, and 1.6 into 1.7. As such, every version branch
'contains' all 'older' branches.

Even though the codebase can diverge quite a bit between the 1.5 and 1.7
tree, these merges tend to be fairly easy, especially since the required
changes are split between the 1.5-1.6 merge and the 1.6-1.7 merge.

'Small' commits with clear purpose, minimal changes & clear commit
messages tend to help a lot in this process as well (especially when
using git-imerge). The squashing performed by Phab as mentioned in some
other messages on the list can be troublesome in this regard... (I'm not
a big fan of squash merges myself, from a maintainer POV).

Nicolas