[webkit-dev] Build slave for JSCOnly Linux MIPS

Filip Pizlo fpizlo at apple.com
Mon Apr 18 17:27:59 PDT 2016


> On Apr 18, 2016, at 4:43 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> 
> On Mon, 2016-04-18 at 15:01 -0700, Geoffrey Garen wrote:
>> GCC 4.8 is three years old.
> 
> Yeah, unfortunately no Linux distros are ever willing to do major
> compiler upgrades, even Fedora is only willing to take minor compiler
> upgrades, so our willingness to support old compilers is proportional
> to the size of our user base eligible for updates. :/

I am sympathetic to the principle that we should support the compilers that ship on the most popular versions of Linux.  I’d like to understand if that argument is sufficient to support GCC 4.8.

Can you clarify, is it the case that if I installed the latest stable Fedora, I’d get GCC 4.8?

> 
> I understand resistance to restoring support for a compiler we
> previously decided to drop, so let me tone down my request: I just ask
> that when we decide to drop support for a compiler, we consider which
> major distros actually shipping our updates still use that compiler, so
> we can get a feel for how many users will stop getting WebKit updates
> as a consequence. We've just recently gotten to the point where a few
> distros are beginning to take our updates, and I'm really hoping to
> facilitate this by maintaining support for the compilers these distros
> are using as long as possible.
> 
> It's really annoying to be stuck catering to older compilers, but I
> don't see any good solution to this without throwing users under the
> bus. :(

I’m sympathetic to this.

> 
>> I don’t think we should put a three year hold on all current and
>> future C++ language features.
>> 
>> Vendors that want to ship security updates to old, stable OS’s should
>> maintain a branch that cherry-picks fixes from trunk and applies
>> build fixes as necessary, rather than holding back development in
>> trunk.
> 
> I'm not aware of any distributor that has ever attempted to seriously
> backport security fixes; not even enterprise distros like RHEL do this.
> Reality is that distros only ship what we release upstream.

Can you clarify what you mean by “backport”?  I’m trying to get a picture of how your releases work.  For example, are you saying that RHEL wouldn’t take a security update that you backported, or that they won’t invest energy into backporting it themselves?

> 
>>> It's unfortunate as of course we want to be able to use new
>> language
>>> features, but we need to balance this with the desire to ensure our
>>> updates reach users.
>> 
>> I don’t think that shipping trunk as a security update on very old
>> platforms is a viable strategy.
> 
> Nobody ships trunk, they ship our stable releases, which branch off of
> trunk every six months. We don't have the resources to maintain
> compiler support outside of trunk.

How many changes are required to make GCC 4.8 work?  I think this will provide important context for this discussion.

-Filip


> 
> Michael
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



More information about the webkit-dev mailing list