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

Reply via email to