Re: [PATCH, 4.2] Backport Geode optimizations

[Mike Stump <mrs at apple dot com>]

On May 22, 2007, at 10:28 PM, Andrew Pinski wrote:
> Except we already kept out SSSE3 support from 4.2, why would this  
> be different.

 We maximize the goodness of a release by using judgement.  Not  
using judgment means we just wake up in the morning, slap a release  
tag on it and roll it out to the ftp site, we don't do that.  Part of  
using judgement means making choice between two things using all  
available, relevant information and ones instincts.  My experience is  
that the content of a patch can radically alter the quality of a  
patch, so, examining the patch itself it necessary for  
consideration.  Now, on the other side, why consider it for a release  
branch?  For the goodness it brings weighed against the risk of  
badness.  Take for example a port that has been proven to not work  
well.  Accepting any patch that makes it better, makes for a better  
release, so the tendency should be to put all these sorts of patches  
in to reduce the likelihood of a bad release, and people shouldn't  
give the maintainer of that port a hard time for doing so.  Well  
designed software allows for the addition of new features and  
functionality with no risk or very little risk to the base set of  
features and functionalities.  In that case, it doesn't hurt a  
release to so add them, assuming that they represent the direction we  
want to go.

Tuning parameters are they types of things that are a perfect fit for  
a minor release.  Time to market is short, a good thing,  
applicability of the compiler to new chips, also a good thing,  
chances of it generating bad code, should be about zero, chances it  
messing up another target, zero, chances of it messing up a  
difference sub-port of the main port, should be very small, if the  
code is written well.

Please don't discourage people from adding goodness in general,  
because in a totally different case, you felt burned.  That would be  
inappropriate revenge upon an innocent.  If the person submitting the  
patch is the same person that burned you, call it out that way, say,  
you know, the last patch you put in (name of patch here), caused some  
unwanted and unexpected grief (laundry list of PRs here), so, I'd  
like to argue against this patch on that basis.  If there is  
something directly relevant about the patch, say there was unexpected  
fallout from changing tuning parameters in the past on x86, and  
people might overlook that fact, you can say, you know, changing the  
tuning parameters on x86 sometimes introduces badness (list of PRs  
here) because the code is way more fragile than it should be, so, I  
caution against it, and because this chip isn't important enough, I  
think we ought not put it in, as the downside can include bad code  
generation for more popular parts.

I don't see the harm in using judgement.  There is a cost, it takes  
time to backport and to review the work in light of where the work is  
going...  but for those that want to do this, we should let them.   
For example, if the Fortran people, as a whole, want to put in  
radically new features into a minor release, to have a faster cycle  
than gcc would normally offer, there isn't anything inappropriate or  
wrong in my book.  If I were on the Fortran team, and wanted to argue  
against it, I'd feel right at home arguing that case.  If they cannot  
agree in general, then I think they should ask the RM to rule on the  
finer points of the plan so they can impose that plan on the patches  
they approve for the branch.

Mark's policy allows for port maintainers to enhance their ports with  
other than strict regressions on release branches, this is slightly  
different than the policy for the rest of the tree.