Re: PATCH: Fix middle-end/25505

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> Even though the patch has been extensively tested, I think its always a
> good idea to let changes stew on mainline for a while in order to allow the
> folks who use the PL/1 front-end on VAXen the opportunity to complain.  In
> the remote possibility that there is an issue with Ada on Sparc, we'll often
> find out before reverting the change becomes more painful.

FWIW I disagree.  Firstly, I think that the active release branch gets more 
diverse testing than the mainline.   In particular, I would think that PL/1 
on VAX folks are more likely to be playing catch-up on the active release 
branch than on mainline.

Secondly, and more importantly, purposely keeping branches unsynchronized is 
both painful and dangerous.  Painful because this effectively means that 
developers have to put their work for a particular problem on hold for a 
while and later to resume it; now they may simply forget to resume it or have 
something more important to do or be reluctant to delve into a particularly 
tricky problem that would take another couple of hours to understand again.
Dangerous because of "patch crossing": you run into a bug easy enough to fix 
on both mainline and release branch but a patch has been applied for a while 
on the mainline to the offending code and is still pending for the release 
branch.  In this case either you simply don't fix the bug on the release 
branch (easy) or you wait for the pending patch to be applied (painful) or 
you have to evaluate the dependency and the interaction between your patch 
and the pending patch (tricky); and if you eventually go for fixing the bug 
on both branches, the author of the pending patch will very likely run into 
the exact same dilemna when he gets back to the problem...

IMHO the reviewer should make a decision upfront: either the patch is safe 
enough for the release branch and it must be applied simultaneously on both 
branches, or it is not and the PR should be marked as WONTFIX on the release 
branch (unless a safer patch can be devised for the branch).

-- 
Eric Botcazou