> 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 disagree. I've been working on GCC for almost 5 years and you're the only maintainer who has ever requested me to wait before backporting a fix for a regression on a release branch. That may be hard to believe, but I honestly think that I'm not rewriting history here. > As a reviewer I have more comfort and faith in patches that have had more > testing than those that haven't. Given that different branches have > differing stability/certainty requirements, it makes sense that its easier > to get a patch approached for mainline and/or 4.3, than it is for 4.1, > 4.0 or 3.4. In my opinion, it is (almost) always possible to make a judgment a priori. > The obvious question is what can be done to learn from and prevent > repeating the problems of the past. I'd suggest that absolutely no-one > could have forseen that the PR28690 would have adversely affected > MIPS/libgcj. Well, REG_POINTER is a tricky business as HP-UX maintainers can tell you. However, we don't have to hold ourselves to an unrealistic standard; there will always be unexpected interactions, that's OK I'd think. > I'm not sure that applying it immediately to the release branches would > improve things. Likewise, for David's current fix, we know it'll affect > primary platforms that haven't been tested, we just don't know how. So why not give the patch more exposure by putting it on the active release branch sooner than later? > I think one source of the problem is that standards the that I hold > myself to, may potentially be unrealistic for many contributors. Definitely. I'd say that the patches you review are not your babies, only those you write are. :-) -- Eric Botcazou
