This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, 4.2] Backport Geode optimizations


Andrew Pinski wrote:

> Except we already kept out SSSE3 support from 4.2, why would this be
> different.  I am just getting tried of making exceptions for patches
> to be included on the release branch (even though we had a policy
> against that) for adding features.

I assert that exceptions should be the rule.

The reason maintainers are human beings instead of scripts
with pattern matching rules or even Bayesian filters, is
that they can use judgment to selectively apply patches
when they feel like they are very safe, very useful or
a combination.

(I'm not saying that my patch falls under one of these
categories, mine is just a general statement)


>  Also this is just another example of the x86 guys
> taking GCC development over.

Applying a patch that does only impact x86 shouldn't
bother other backend maintainers.

This is the very first x86 patch I submit, but in the
past, I've been allowed to tweak Coldfire and uClinux
support the m68k backend because they were new targets
that were not yet usable out of the box in the FSF tree.


> Sorry for this angry
> message but I guess we need either to change our policy or let nothing
> new (except for new targets which is in our policy by the way) into
> the release branches.

Maybe we just need to call it "guideline" instead of "policy"
or "rule", so it's clear that it can have exceptions for
good reasons.  Maintainer's discretion is what counts anyway, no?


> Plus the distros which care about this can
> backport this patch themselves.

And Fedora did it already, so I'm no longer personally
interested in getting it out.

But I'd like to point out that there's something
fundamentally broken if Vladimir's tuning work takes
2 years to show up in a formal release.  Most CPUs
go out of production much earlier than this! :-)


>  It is not fare to the rest of the GCC
> community if we include one new thing in 4.2.0 and not others.  This
> is the reason behind our policy.  If we want to rethink the policy
> that is fine with me but I guess we should stick to it until the
> policy changes.

I know I'm going to open a big can of worms by saying
this, but anyway: the success of GCC's formal releases
can also be measured by the number of tweaks that
downstream distributors need to apply manually, being
them bugfixes or enhancements.

Both the Linux kernel and Xorg went through this already:
with their old development models, important features
would take over 2 years before being made public.

So all distibutors were forced to spend lots of engineering
resources in backports, which were inevitably lower quality.
As an additional disadvantage, custom versions were
dangerously diverging between distributions.

Now that stable kernels and X servers are available
in a timely fashion, the need for such customizations
has been considerably reduced.

The bottom line is: let's have shorter release cycles.

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]