Tentative high-level plans for 7.10.1

[Nicolas Trangez]

Hello Daniel,

On Mon, 2014-10-06 at 12:46 +0200, Daniel Trstenjak wrote:
> > 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.
> 
> I don't like this practise, because you certainly don't want to always
> incorprocate all commits of one release branch into an other.
> 
> Just think about a hackish bug fix needed to be added in a former
> release, and in a newer release the problem has been solved in a
> completely different way, and now, if you have bad luck, the former
> release branch merges without conflicts into the new one, now getting
> the hackish fix into the new release, which might be even harmful.

Agree, although I think this is less of an issue in practice because we
enforce code reviews for all commits, including 'merge' commits, even if
the merge was 100% automatic (hence we have PRs for '1.5-for-1.6'
branches once in a while). These 'workarounds' are spotted easily during
this process.

Next to that, chances are fairly low a 'hack' won't in any way conflict
with a 'proper fix', since they tend to touch (a portion of) the same
code most of the time (except in build systems maybe). Using
'git-imerge' helps here quite a bit as well, since the conflicts aren't
buried between 100s of unrelated changes (like what git-merge does). 

> IMHO using cherry picking in this case is a lot better manageable.

Yet it has a (IMHO) major drawback: it requires a system next to VCS
(issue tracker or alike) to make sure all fixes are propagated to all
applicable versions, which all too often results in (human) error. "Hey,
we reported this against 1.6.3, and it was fixed in 1.6.4, but now we
upgraded to 1.7.3 which was released after 1.6.4 and the bug is back" is
no good PR.

Anyway, it's not like I intend to push GHC development/maintenance in
any specific direction at all, just wanted to provide some experience
report :-)

Regards,

Nicolas