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 [EMAIL PROTECTED] (650) 331-3385 x713
