Roger Sayle <[EMAIL PROTECTED]> writes: > Once explained, I'd expect most maintainers would make precisely the > same call?
I suppose the counter-argument is that we shouldn't ship 4.2 in its current state. We should either back out the patch that made REG_POINTER more prominent or go with the fix for this PR. From that point of view, there doesn't seem to be much advantage in keeping the 4.2 branch in its current state. Lots of people seem to test release branches -- probably more than mainline -- and I would hope that using the fix from this PR is by far the strongest contender. I think we'd be doing ourselves a favour by going with what we expect to be the final fix and getting as much testing of it as possible. After all, it's not difficult to test & apply a patch to a branch at the same time as mainline, or to revert it in the same way. Also, having patches on mainline and not a release branch can cause quite a bit of confusion. Witness what happend with PR 28243, where I fixed something on mainline, but it was not directly approved for a release branch. Then Eric B. worked around the same problem on the release branch and forward-ported the work-around to mainline, where it wasn't really needed. (It's quite common for a testcase to only fail on a release branch, and pass on mainline due to unrelated code generation changes, so there was no reason for Eric to be suspicious.) I just don't think it's as obvious a call as your question above makes out. There are downsides to this approach too, especially when no one person is in overall charge of repository (mainline and branch). Richard
