Re: [webkit-dev] update GCC version?

[Alberto Garcia]

On Mon, Jan 09, 2017 at 04:39:44PM +0100, Carlos Alberto Lopez Perez wrote:

> I strongly oppose to do (a). Also, it is false that Debian doesn't
> take our updates. They take our updates in the backports repository
> for stable.

The main reason why that happens is that the WebKitGTK+ stable updates
not only include security fixes but also several other changes, which
is not how things usually work in Debian:

https://www.debian.org/security/faq#oldversion

Since WebKitGTK+ is conservative regarding API/ABI changes I don't
think there's much of a risk there, but there's definitely a risk
of introducing regressions, and unlike Mozilla or Chromium updating
WebKitGTK+ can affect or potentially break any of the many packages
that depend on it.

That's why I started uploading it to the backports repository, and my
plan is to keep the backports always up to date.

Berto
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Alex Christensen]

> On Jan 9, 2017, at 7:39 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
> On 09/01/17 01:09, Michael Catanzaro wrote:
>> On Sun, 2017-01-08 at 18:59 +0100, z...@falconsigh.net wrote:
>>> For the record, GCC 5 has complete C++14 support. The current
>>> requirement is 4.9, so the bump would be minimal.
>>> https://gcc.gnu.org/projects/cxx-status.html#cxx14
>> We would need to redefine our dependencies policy:
>> 
>> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> 
>> We just recently crafted that policy. I kinda like it because it
>> provides a clear formula for deciding whether a compiler is too new to
>> be required or not. It means we would support GCC 4.9 until roughly
>> next spring/summer, one year from the next Debian release. We could
>> either (a) drop Debian from the policy, which I support doing anyway
>> because it does not take our security updates, or we could (b) define
>> the policy in terms of runtime dependencies, rather than build
>> dependencies (which I think Carlos Garcia wanted to do anyway). Either
>> way makes it more likely that distributions will get cut off and choose
>> to not provide WebKit security updates. I would prefer not to do (b),
>> because in practice distributions will just not take our updates if
>> they can't use their default compiler.
>> 
> 
> I strongly oppose to do (a). Also, it is false that Debian doesn't take
> our updates. They take our updates in the backports repository for stable.
> 
> I also don't like (b).
> 
> Another idea is: (c) Drop the "one year after the release" requirement.
> Which means that we could update to minimum GCC version to 5.3 (the one
> in last Ubuntu LTS) when Debian 9 is released (which hopefully is
> expected to happen around the middle of 2017).
> 
> A date that I guess will be near enough to when VS2017 is released.
A mid-2017 upgrade would be quite reasonable.
> 
> This will mean that instead of supporting up to 3-year old dependencies
> we will only support up to 2-year old ones.
> I'm not particular enthusiast about this, but I'm ready to understand
> that supporting 3-year old dependencies is not realistic on a project
> like WebKit.
> 
>> Keep in mind that for a distro to upgrade from GCC 4.9 -> 5.0 is weeks
>> of effort unless you build GCC with the flag that turns on the old C++
>> ABI, but you have to switch to the new ABI eventually, so might as well
>> do it at the same time. I have to support WebKit for a distribution
>> that has been delaying the upgrade for this reason. GCC upgrades are
>> expensive and not fun. Even turning off the ABI switch, upgrading GCC
>> means lots of obscure C++ build failures in packages you're not
>> familiar with.
>> 
>> Michael
> 
> Another (maybe easier) way forward for building it on distros that have
> libstdc++ < 5.0 is to use clang.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Konstantin Tokarev]

09.01.2017, 20:53, "Michael Catanzaro" :
> On Mon, 2017-01-09 at 16:56 +0100, Carlos Alberto Lopez Perez wrote:
>>  Can you please explain how you reach that conclusion?
>>  Do you have any data to back up such claim?
>
> No, I don't have data, but it seems extremely naive to assume that any
> significant subset of users use backports. It is not enabled by
> default, and we know users almost never change defaults.

I believe users of WebKit can be reasonably split into two groups:
1) desktop
2) server

In case of desktop, I can assure you that it's genuinely hard to use distro 
like Debian stable or CentOS on desktop without any additional repos. Backports 
repo comes as a first candidate in case of Debian.

In case of server, indeed people won't change defaults until they very much 
need it. However, WebKit is not a typical server software, so I think it would 
be reasonable to assume server users know what they are doing.


> Reasonable
> users assume they are receiving security updates by default.
>
> This seems to have diverged from the topic at hand, though. I agree
> your proposal to remove the +1 year requirement is better than both of
> mine, so if we decide to bump the compiler requirement that's the one
> we should choose.
>
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Mon, 2017-01-09 at 16:56 +0100, Carlos Alberto Lopez Perez wrote:
> Can you please explain how you reach that conclusion?
> Do you have any data to back up such claim?

No, I don't have data, but it seems extremely naive to assume that any
significant subset of users use backports. It is not enabled by
default, and we know users almost never change defaults. Reasonable
users assume they are receiving security updates by default.

This seems to have diverged from the topic at hand, though. I agree
your proposal to remove the +1 year requirement is better than both of
mine, so if we decide to bump the compiler requirement that's the one
we should choose.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Carlos Alberto Lopez Perez]

On 09/01/17 16:47, Michael Catanzaro wrote:
> On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
>> I strongly oppose to do (a). Also, it is false that Debian doesn't
>> take
>> our updates. They take our updates in the backports repository for
>> stable.
> 
> Nobody uses that. Users expect to receive security updates in the
> security repository.
> 

Can you please explain how you reach that conclusion?
Do you have any data to back up such claim?


I'm a Debian user and I use the backports repository extensively.
And I have the feeling that most desktop users of Debian stable also use it.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
> I strongly oppose to do (a). Also, it is false that Debian doesn't
> take
> our updates. They take our updates in the backports repository for
> stable.

Nobody uses that. Users expect to receive security updates in the
security repository.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Michael Catanzaro]

On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
> Another idea is: (c) Drop the "one year after the release"
> requirement.
> Which means that we could update to minimum GCC version to 5.3 (the
> one
> in last Ubuntu LTS) when Debian 9 is released (which hopefully is
> expected to happen around the middle of 2017).
> 
> A date that I guess will be near enough to when VS2017 is released.
> 
> This will mean that instead of supporting up to 3-year old
> dependencies
> we will only support up to 2-year old ones.
> I'm not particular enthusiast about this, but I'm ready to understand
> that supporting 3-year old dependencies is not realistic on a project
> like WebKit.

I think it is totally realistic to support 3-year old dependencies.
There's absolutely no reason we cannot do it if we want to. The latest
compiler features are nice-to-haves, not requirements.

But I agree that this would be a good solution if we want to bump the
GCC requirement sooner. As you pointed out, it would allow us to do
that this summer rather than next summer.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Konstantin Tokarev]

09.01.2017, 18:47, "Michael Catanzaro" :
> On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
>>  I strongly oppose to do (a). Also, it is false that Debian doesn't
>>  take
>>  our updates. They take our updates in the backports repository for
>>  stable.
>
> Nobody uses that. Users expect to receive security updates in the
> security repository.

"Nobody" and "not everybody" are different quantifiers.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Carlos Alberto Lopez Perez]

On 09/01/17 01:09, Michael Catanzaro wrote:
> On Sun, 2017-01-08 at 18:59 +0100, z...@falconsigh.net wrote:
>> For the record, GCC 5 has complete C++14 support. The current
>> requirement is 4.9, so the bump would be minimal.
>> https://gcc.gnu.org/projects/cxx-status.html#cxx14
> We would need to redefine our dependencies policy:
> 
> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> 
> We just recently crafted that policy. I kinda like it because it
> provides a clear formula for deciding whether a compiler is too new to
> be required or not. It means we would support GCC 4.9 until roughly
> next spring/summer, one year from the next Debian release. We could
> either (a) drop Debian from the policy, which I support doing anyway
> because it does not take our security updates, or we could (b) define
> the policy in terms of runtime dependencies, rather than build
> dependencies (which I think Carlos Garcia wanted to do anyway). Either
> way makes it more likely that distributions will get cut off and choose
> to not provide WebKit security updates. I would prefer not to do (b),
> because in practice distributions will just not take our updates if
> they can't use their default compiler.
> 

I strongly oppose to do (a). Also, it is false that Debian doesn't take
our updates. They take our updates in the backports repository for stable.

I also don't like (b).

Another idea is: (c) Drop the "one year after the release" requirement.
Which means that we could update to minimum GCC version to 5.3 (the one
in last Ubuntu LTS) when Debian 9 is released (which hopefully is
expected to happen around the middle of 2017).

A date that I guess will be near enough to when VS2017 is released.

This will mean that instead of supporting up to 3-year old dependencies
we will only support up to 2-year old ones.
I'm not particular enthusiast about this, but I'm ready to understand
that supporting 3-year old dependencies is not realistic on a project
like WebKit.

> Keep in mind that for a distro to upgrade from GCC 4.9 -> 5.0 is weeks
> of effort unless you build GCC with the flag that turns on the old C++
> ABI, but you have to switch to the new ABI eventually, so might as well
> do it at the same time. I have to support WebKit for a distribution
> that has been delaying the upgrade for this reason. GCC upgrades are
> expensive and not fun. Even turning off the ABI switch, upgrading GCC
> means lots of obscure C++ build failures in packages you're not
> familiar with.
> 
> Michael

Another (maybe easier) way forward for building it on distros that have
libstdc++ < 5.0 is to use clang.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

Thank you for your suggestions!
Based on our discussion, I've uploaded the patch[1] :)

[1]: https://bugs.webkit.org/show_bug.cgi?id=166678

Regards,
Yusuke Suzuki

On Fri, Jan 6, 2017 at 2:50 PM, Yusuke SUZUKI  wrote:

> On Fri, Jan 6, 2017 at 2:43 PM, Maciej Stachowiak  wrote:
>
>>
>> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI  wrote:
>>
>> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak  wrote:
>>
>>>
>>> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
>>>
>>>
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI 
>>> wrote:
>>>
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  wrote:
>>>
 I understand the appeal of “org.webkit” and structured names but
 personally I would prefer to read names that look like titles and are made
 up of words with spaces, like these:

 “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
 “WebKit: JavaScript DFG Compiler” rather than
 “org.webkit.jsc.DFGCompiler”.

 Not sure how well that would generalize to all the different names.

 I like the idea of having a smart way of automatically making a shorter
 name for the platforms that have shorter length limits.

>>>
>>> One interesting idea I've come up with is that,
>>>
>>> 1. specifying "org.webkit.ImageDecoder"
>>> 2. In Linux, we just use "ImageDecoder" part.
>>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>>>
>>>
>>> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
>>> part is ever going to be used?
>>> Is that because Windows could use “org.webkit.”?
>>>
>>>
>>> What about if you just specify "Image Decoder" and we automatically
>>> convert that to either "ImageDecoder" or "WebKit: Image Decoder" based on
>>> platform thread name limits? Is there any case where we want a prefix other
>>> than "WebKit: "?
>>>
>>
>> Yeah. For the prefix case, automatically adding "WebKit: " is fine. The
>> current ToT has the name like "com.apple.IPC.ReceiveQueue".
>> Previously I thought that we may need to convert it to "Apple WebKit:" or
>> something like that.
>> But now, I think simply using "WebKit: IPC Receive Queue" is fine.
>>
>> But I think automatically changing "ImageDecoder" to "Image Decoder" does
>> not work well with long names.
>> There is a name like "AsynchrnousDisassembler". It is >= 15 characters.
>> "AsynchronousDisas" is not good for Linux.
>> On the other hand, using "AsyncDisasm" => "WebKit: AsyncDisasm" is not
>> good for macOS.
>> For macOS, we can choose more readable name like "WebKIt: Asynchronous
>> Disassembler".
>>
>> So, I think Geoffrey's suggestion works well: using long / short name
>> pairs. Like,
>>
>> ThreadName { "Asynchronous Disassembler", "AsyncDisasm" } // { const
>> char*, const char* }
>>
>> // OR,
>> CREATE_THREAD_NAME("Asynchronous Disassembler", "AsyncDisasm") macro =>
>> generating ThreadName("WebKit: Asynchronous Disassembler") on macOS,
>> ThreadName("AsyncDisasm") on Linux
>>
>>
>> If there's a good set of "short name" and "long name" length limits, it
>> would be cool if we could check the length at compile time, which seems
>> more feasible with the macro.
>>
>>
> Yeah! That's what I would like to do. The typical ThreadName
> implementation would become the following.
>
> class ThreadName {
> public:
> template
> explicit ThreadName(const char ()[N])
> : m_name(name)
> {
> #if OS(LINUX)
> static_assert(N <= 16, "");
> #else if OS(WINDOWS)
> static_assert(N <= 32, "");
> #endif
> }
>
> operator const char*()
> {
> return m_name;
> }
>
> private:
> const char* m_name;
> };
>
>
>
>> Regards,
>> Maciej
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev