Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

[Mark Mitchell <mark at codesourcery dot com>]

Eric Botcazou wrote:
> > Finally before I finish the retrospective part of this e-mail, I'll
> > point out this isn't a sudden recent unilateral policy decision, but
> > purely a crystallization of the prescribed GCC work-flow outlined in
> > contributing.html that has been refined over many years.

I've reviewed this thread, because there was some discussion about how 
to handle release branches.

In general, I'd prefer that all patches to fix regressions go on the 
release branch at the same time as they go to mainline.  However, I have 
myself failed to do that at times; I presently have a few C++ patches 
which need backporting to 4.1, and I have not yet done that.  At a 
minimum, in such a case, there should be a PR open for the release 
branch failure, and it should note the presence of the patch on 
mainline.  (I've done that for my C++ patches, in that the check-in 
messages on mainline are in the PRs.)  From my perspective, as RM, the 
critical thing is that we have a PR and a record of the patch, so that 
as we approach the release we know we have a bug, and we know we have an 
option available to fix it.

I also recognize that there may sometimes be patches that appear risky, 
and that we therefore want to apply them to mainline before applying 
them to release branches too.  I think that's perfectly appropriate.  In 
other words, I think this is a judgment call, and I think maintainers 
should be free to make it.  But, in general, please do try to put 
patches on release branches, especially if they fix P1 regressions. 
Sacrificing code quality for correctness is the right tradeoff for a 
release branch, if we have to pick, so if a patch is "only" going to 
pessimize code, it should be a very strong candidate for a release branch.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713