This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Fix middle-end/25505
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Josh Conner <jconner at apple dot com>, iant at google dot com, jason at redhat dot com, richard dot guenther at gmail dot com
- Date: Wed, 20 Sep 2006 09:04:02 +0200
- Subject: Re: PATCH: Fix middle-end/25505
- References: <Pine.LNX.email@example.com>
> 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).