Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-19 Thread Alexey Proskuryakov


> 19 июня 2020 г., в 1:11 PM, Mark Lam  написал(а):
> 
> 
> 
>> On Jun 19, 2020, at 10:24 AM, Geoffrey Garen > > wrote:
>> 
 On Jun 19, 2020, at 8:04 AM, Geoffrey Garen >>> > wrote:
 
 Can you explain more about what "O3 with no-inlining” is? How does 
 --force-opt=O3 avoid inlining? Would this fully resolve Simon concern 
 about stack traces, or would something still be different about stack 
 traces?
>>> There doesn't exist a way to do this now, but it'd be trivial to add a way. 
>>> I won't claim it fixes all stack traces differences, but I'd think 
>>> compiling using "-fno-inline -fno-optimize-sibling-calls" would get us 
>>> pretty far in crashing stack traces being similar enough.
>> 
>> Sounds good.
>> 
>> I think we should try to refine the proposal along these lines, to minimize 
>> the downsides. I won’t speak for Simon, but for me, being able to ensure a 
>> clear backtrace from a bot would be a big improvement.
>> 
 And again, I think this discussion would get a lot more focused if the 
 change could apply only to JSC code, and not also to WTF code.
>>> I believe Mark's proposal, initially, is just to make JSC do this. So I 
>>> don't see the point of compiling WTF differently. JSC can kick off its own 
>>> build, and run Debug+O3 tests faster than it can run Debug+O0 tests. Given 
>>> people working on JSC want this, and people working on JSC defend these 
>>> tests, and that these test results are more stable (see below), we should 
>>> make this change for JSC.
>>> 
>>> I was trying to convince folks defending non-JSC testing, that they too, 
>>> should want this. I'm not going to pull teeth here. If folks want their 
>>> tests to take ~10x longer to run, they're entitled to make that tradeoff.
>> 
>> Got it.
> 
> I'm of the same mind as Saam.  We want this change for the JSC bots, and from 
> the time measurements I’ve collected, we can afford to do a clean build for 
> the JSC Debug test runs using O3, and still come out way ahead.

This seems like a reasonable plan. You didn't mention what hardware you 
measured with, but it seems certain to be beneficial on any current hardware.

I need to mention that we saw unexplained and very large impact on JSC test 
speed from enabling/disabling TCSM. That may be a good thing to look into while 
optimizing JSC test speed.

- Alexey


> As for non-JSC test runs, I have not actually measured what the time savings 
> are.  Given there is resistance to going with O3 there, we don’t have to 
> share the build artifacts for running the tests.  JSC test runs should be 
> able to just build JSC for each O3 Debug JSC test run and it is still a win 
> over the current status quo i.e. test runs never complete.
> 
> Regarding Geoff’s earlier question about whether I know for sure that 
> switching to O3 will fix the current Debug JSC bot failures to run tests, the 
> answer is I’m not certain.  The failure is a timeout due to the master bot 
> not seeing any output from the tester bot for more than 20 minutes.  I’ve not 
> been able to reproduce this yet.  But with a Debug build test run taking 4+ 
> hours, it can only be a progression to switch the Debug JSC test bots to O3.
> 
> Mark
> 
> 
>> 
 And again, on the run more tests front, it would be helpful to know 
 whether this change was enough to get the stress tests running or not.
>>> My experience running the tests locally supports this fully. I don't get 
>>> timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd 
>>> get timeouts all the time, and the total test run would take ~4-8 hours. We 
>>> can wait for official confirmation from Mark.
>> 
>> Alexey, do the JSC stress tests run now on bots? If not, how fast would they 
>> need to run in order to be eligible to run on bots?
>> 
>> Thanks,
>> Geoff
>> 
>>> 
>>> - Saam
>>> 
 
 Thanks,
 Geoff
 
> On Jun 18, 2020, at 9:30 PM, Saam Barati  > wrote:
> 
> Why are we insisting on doing something on the bots that takes ~10x 
> longer to run than necessary? I’d rather have that time spent running 
> more tests.
> 
> Overall, how we’re doing things now feels like a bad allocation of bot 
> resources. The differences I see between O3 with no-inlining vs O0 is:
> - Some race conditions will behave differently. Race conditions are 
> already non predictable. I don’t think we’re losing anything here.
> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t 
> in O0, and vice versa. In general, we probably care more about O3 
> compiler bugs than O0, since we don’t ship O0, but ship a lot of O3.
> 
> (And if we’re going to insist on “I want it to run what I build at my 
> desk”: I run debug with O3 at my desk, and I can run debug tests in a 
> reasonable amount of time now.)
> 
> In evaluating what’s the better 

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-19 Thread Alexey Proskuryakov


> 19 июня 2020 г., в 10:24 AM, Geoffrey Garen  написал(а):
> 
>>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen >> > wrote:
>>> 
>>> Can you explain more about what "O3 with no-inlining” is? How does 
>>> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern about 
>>> stack traces, or would something still be different about stack traces?
>> There doesn't exist a way to do this now, but it'd be trivial to add a way. 
>> I won't claim it fixes all stack traces differences, but I'd think compiling 
>> using "-fno-inline -fno-optimize-sibling-calls" would get us pretty far in 
>> crashing stack traces being similar enough.
> 
> Sounds good.
> 
> I think we should try to refine the proposal along these lines, to minimize 
> the downsides. I won’t speak for Simon, but for me, being able to ensure a 
> clear backtrace from a bot would be a big improvement.

Enabling some level of optimization is reasonable; whether it should be -O3 
with inlining disabled or -Og is a technical question that probably can't be 
answered without hard data. Also, building locally in the same way as bots do 
could be a show stopper, as people don't like slow builds.

>>> And again, I think this discussion would get a lot more focused if the 
>>> change could apply only to JSC code, and not also to WTF code.
>> I believe Mark's proposal, initially, is just to make JSC do this. So I 
>> don't see the point of compiling WTF differently. JSC can kick off its own 
>> build, and run Debug+O3 tests faster than it can run Debug+O0 tests. Given 
>> people working on JSC want this, and people working on JSC defend these 
>> tests, and that these test results are more stable (see below), we should 
>> make this change for JSC.
>> 
>> I was trying to convince folks defending non-JSC testing, that they too, 
>> should want this. I'm not going to pull teeth here. If folks want their 
>> tests to take ~10x longer to run, they're entitled to make that tradeoff.
> 
> Got it.

To do this only for JSC builds, we'd need separate builders and storage, so it 
becomes a question of allocating more resources, not just switching over to a 
different configuration. While EWS builds for JSC independently, post-commit 
testing shares build artifacts across all testers.

>>> And again, on the run more tests front, it would be helpful to know whether 
>>> this change was enough to get the stress tests running or not.
>> My experience running the tests locally supports this fully. I don't get 
>> timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd 
>> get timeouts all the time, and the total test run would take ~4-8 hours. We 
>> can wait for official confirmation from Mark.
> 
> Alexey, do the JSC stress tests run now on bots? If not, how fast would they 
> need to run in order to be eligible to run on bots?

I don't think that there is a simple answer, as certain variations of stress 
tests get disabled on certain bots, JSC tests have a lot of variations that are 
handpicked. I wouldn't even know how to find the complex answer, but perhaps 
you can get the answer from 

- Alexey



> Thanks,
> Geoff
> 
>> 
>> - Saam
>> 
>>> 
>>> Thanks,
>>> Geoff
>>> 
 On Jun 18, 2020, at 9:30 PM, Saam Barati >>> > wrote:
 
 Why are we insisting on doing something on the bots that takes ~10x longer 
 to run than necessary? I’d rather have that time spent running more tests.
 
 Overall, how we’re doing things now feels like a bad allocation of bot 
 resources. The differences I see between O3 with no-inlining vs O0 is:
 - Some race conditions will behave differently. Race conditions are 
 already non predictable. I don’t think we’re losing anything here.
 - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t 
 in O0, and vice versa. In general, we probably care more about O3 compiler 
 bugs than O0, since we don’t ship O0, but ship a lot of O3.
 
 (And if we’re going to insist on “I want it to run what I build at my 
 desk”: I run debug with O3 at my desk, and I can run debug tests in a 
 reasonable amount of time now.)
 
 In evaluating what’s the better setup, I think it’s helpful to think about 
 this from the other side. Let’s imagine we had Debug+O3 as our current 
 setup. And someone proposed to move it to O0 and make our tests take ~10x 
 longer. I think that’d be a non-starter.
 
 - Saam
 
> On Jun 17, 2020, at 9:48 PM, Simon Fraser  > wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what 
> I build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam > > wrote:
>> 
>> Hi folks,
>> 
>> We're 

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-19 Thread Alexey Proskuryakov


> 19 июня 2020 г., в 9:59 AM, Mark Lam  написал(а):
> 
> 
> 
>> On Jun 19, 2020, at 9:53 AM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> 
>> 
>>> 18 июня 2020 г., в 9:30 PM, Saam Barati >> <mailto:sbar...@apple.com>> написал(а):
>>> 
>>> Why are we insisting on doing something on the bots that takes ~10x longer 
>>> to run than necessary? I’d rather have that time spent running more tests.
>> 
>> Replying to this point specifically, I wanted to point out that WebKit tests 
>> take 2x longer in debug, not 10x longer. JSC tests take 3.6x longer.
> 
> Since I collected real data on this last night on the actual bot that runs 
> the JSC stress tests, I’ll share the data here:
> 
> Build time
> A clean build using buid-jsc for a normal Debug build on bot638 takes about 
> 4.5 minutes.
> A clean build using build-jsc for a --force-opt=O3 Debug build on bot638 
> takes about 6 minutes.
> 
> Test run time
> Running with a regular Debug build, the test completed in about 4 hours 41 
> minutes with 1 timeout.
> Running with a --force-opt=O3 Debug build, the test completed in about 39 
> minutes with 0 timeouts.
> 
> The difference in test run time is 281 minutes vs 29 minutes.  That is a 7.2x 
> ratio, not 3.6x.

https://build.webkit.org/builders/Apple-Catalina-Debug-JSC-Tests/builds/1080 - 
4 hrs, 5 secs
https://build.webkit.org/builders/Apple-Catalina-Release-JSC-Tests/builds/2546 
- 1 hrs, 6 mins, 27 secs

That's 3.6x.

- Alexey



>>> Overall, how we’re doing things now feels like a bad allocation of bot 
>>> resources. The differences I see between O3 with no-inlining vs O0 is:
>> 
>> Last time this was discussed, we talked about -Og, which is specifically 
>> designed for the purpose I believe. Where do we stand on understanding and 
>> adopting that?
> 
> I tried -Og last time after your suggestion, and I remember thinking that the 
> perf was not acceptable back then.  I’ll collect the data again and report 
> back with real number later today.
> 
> Mark
> 
>> 
>> - Alexey
>> 
>>> - Some race conditions will behave differently. Race conditions are already 
>>> non predictable. I don’t think we’re losing anything here.
>>> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in 
>>> O0, and vice versa. In general, we probably care more about O3 compiler 
>>> bugs than O0, since we don’t ship O0, but ship a lot of O3.
>>> 
>>> (And if we’re going to insist on “I want it to run what I build at my 
>>> desk”: I run debug with O3 at my desk, and I can run debug tests in a 
>>> reasonable amount of time now.)
>>> 
>>> In evaluating what’s the better setup, I think it’s helpful to think about 
>>> this from the other side. Let’s imagine we had Debug+O3 as our current 
>>> setup. And someone proposed to move it to O0 and make our tests take ~10x 
>>> longer. I think that’d be a non-starter.
>>> 
>>> - Saam
>>> 
>>>> On Jun 17, 2020, at 9:48 PM, Simon Fraser >>> <mailto:simon.fra...@apple.com>> wrote:
>>>> 
>>>> I also object to losing good stack traces for crashes on Debug bots.
>>>> 
>>>> Also, I don't think Debug bots should build something different from what 
>>>> I build at my desk.
>>>> 
>>>> Simon
>>>> 
>>>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >>>> <mailto:mark@apple.com>> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>>> <http://build.webkit.org/> Debug build and test bots to building with the 
>>>>> following set first:
>>>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>>>> 
>>>>> This means the Debug builds will be built with optimization level forced 
>>>>> to O3.
>>>>> 
>>>>> Why are we doing this?
>>>>> 1. So that the JSC EWS will start catching ASSERT failures.
>>>>> 2. JSC stress test Debug bots have been timing out and not running tests 
>>>>> at all.  Hopefully, this change will fix this issue.
>>>>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>>>>> 
>>>>> The downside: crash stack traces will be like Release build stack traces. 
>>>>>  But I don’t think we should let this deter us.  It’s not like there’

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-19 Thread Alexey Proskuryakov


> 18 июня 2020 г., в 9:30 PM, Saam Barati  написал(а):
> 
> Why are we insisting on doing something on the bots that takes ~10x longer to 
> run than necessary? I’d rather have that time spent running more tests.

Replying to this point specifically, I wanted to point out that WebKit tests 
take 2x longer in debug, not 10x longer. JSC tests take 3.6x longer.

> Overall, how we’re doing things now feels like a bad allocation of bot 
> resources. The differences I see between O3 with no-inlining vs O0 is:

Last time this was discussed, we talked about -Og, which is specifically 
designed for the purpose I believe. Where do we stand on understanding and 
adopting that?

- Alexey

> - Some race conditions will behave differently. Race conditions are already 
> non predictable. I don’t think we’re losing anything here.
> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in 
> O0, and vice versa. In general, we probably care more about O3 compiler bugs 
> than O0, since we don’t ship O0, but ship a lot of O3.
> 
> (And if we’re going to insist on “I want it to run what I build at my desk”: 
> I run debug with O3 at my desk, and I can run debug tests in a reasonable 
> amount of time now.)
> 
> In evaluating what’s the better setup, I think it’s helpful to think about 
> this from the other side. Let’s imagine we had Debug+O3 as our current setup. 
> And someone proposed to move it to O0 and make our tests take ~10x longer. I 
> think that’d be a non-starter.
> 
> - Saam
> 
>> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
>> 
>> I also object to losing good stack traces for crashes on Debug bots.
>> 
>> Also, I don't think Debug bots should build something different from what I 
>> build at my desk.
>> 
>> Simon
>> 
>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >> > wrote:
>>> 
>>> Hi folks,
>>> 
>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>  Debug build and test bots to building with the 
>>> following set first:
>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>> 
>>> This means the Debug builds will be built with optimization level forced to 
>>> O3.
>>> 
>>> Why are we doing this?
>>> 1. So that the JSC EWS will start catching ASSERT failures.
>>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>>> all.  Hopefully, this change will fix this issue.
>>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>>> 
>>> The downside: crash stack traces will be like Release build stack traces.  
>>> But I don’t think we should let this deter us.  It’s not like there’s no 
>>> stack information.  And just as we do with debugging Release build test 
>>> failures, we can always do a Debug build locally to do our debugging.
>>> 
>>> We would like to apply this change to all Debug build and test bots, not 
>>> just the JSC ones.  Does anyone strongly object to this change?
>>> 
>>> Thanks.
>>> 
>>> Cheers,
>>> Mark
>>> 
>>> ___
>>> 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
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Alexey


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


Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-17 Thread Alexey Proskuryakov

I frequently find it critically useful to see stack traces from debug builds, 
because of no inlining. So I don't think that we should do this. A local build 
does not help when the issue is not readily reproducible.

- Alexey


> 17 июня 2020 г., в 1:36 PM, Mark Lam  написал(а):
> 
> Hi folks,
> 
> We're planning to switch the JSC EWS bot and build.webkit.org 
>  Debug build and test bots to building with the 
> following set first:
> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
> 
> This means the Debug builds will be built with optimization level forced to 
> O3.
> 
> Why are we doing this?
> 1. So that the JSC EWS will start catching ASSERT failures.
> 2. JSC stress test Debug bots have been timing out and not running tests at 
> all.  Hopefully, this change will fix this issue.
> 3. Tests will run to completion faster and we’ll catch regressions sooner.
> 
> The downside: crash stack traces will be like Release build stack traces.  
> But I don’t think we should let this deter us.  It’s not like there’s no 
> stack information.  And just as we do with debugging Release build test 
> failures, we can always do a Debug build locally to do our debugging.
> 
> We would like to apply this change to all Debug build and test bots, not just 
> the JSC ones.  Does anyone strongly object to this change?
> 
> Thanks.
> 
> Cheers,
> Mark
> 
> ___
> 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] Platform.h vs. makefiles

2020-05-11 Thread Alexey Proskuryakov

I see substantial appeal in having a separate data file, however I'm not sure 
if it can inform IDE parsing and syntax highlighting for code enabled/disabled 
at compile time. Header files seem like they would get that right more often.

- Alexey


> 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak  написал(а):
> 
> 
> I think the best way to configure WebKit is to use a separate data file, 
> neither a header nor a makefile or similar, that defines the options in a 
> single place with clear syntax. Then everything else is generated from that. 
> Such a system could cover runtime flags as well, which are even more 
> scattered around the project than compile-time flags.
> 
> Moving logic from build files to the header is probably a move in the right 
> direction, though of course it carries risk, particularly for less tested 
> configurations.
> 
> -  Maciej
> 
>> On May 10, 2020, at 5:13 PM, Darin Adler  wrote:
>> 
>> Hi folks.
>> 
>> The Platform.h configuration file family has been useful for WebKit for a 
>> long time. We created it to try to organize configuration options in WebKit 
>> so the would not be spread out through the whole project.
>> 
>> One way to look at these, particularly the ENABLE options, is as a set of 
>> configuration options that let each consumer of the WebKit source code 
>> create a unique flavor of WebKit with the particular features they want 
>> enabled turned on and others turned off. Another is to think of this as a 
>> mechanism for keeping decisions made by the WebKit contributors organized 
>> and easy to understand.
>> 
>> If these truly are WebKit consumer options, then it’s important they be set 
>> as part of the build process. The macros can be defined with a build and 
>> configuration system outside WebKit, and the Platform.h headers should 
>> interpret those values correctly.
>> 
>> On the other hand, if we are just trying to keep our decisions straight, 
>> then it would be best if the logic for what is on and what is off by in the 
>> header files, written with preprocessor macro logic, and not spread across 
>> multiple make files and scripts.
>> 
>> Thus I think the pattern on macOS, for example, of setting these in 
>> .xcconfig files doesn’t make a lot of sense. I think the .xcconfig files 
>> should compute the things that need to be determined about the build 
>> environment, but the configuration decisions should be in files like 
>> PlatformHaveCocoa.h, for example.
>> 
>> I think the guideline should be like this:
>> 
>> All code to compute configuration should be in the Platform.h files, not in 
>> makefiles, with only the following exceptions:
>> 
>> 1) Options like ENABLE(XXX) that some ports wish to offer as options to 
>> people building WebKit can have overridden values in makefiles. But even 
>> these options should have sensible defaults in the Platform.h headers that 
>> express the current status of the port from the point of view of the port’s 
>> maintainers. Ideally we’d find a way to not repeat these default settings 
>> twice.
>> 
>> 2) In some cases, the build machinery needs to contribute to things like 
>> feature detection. So on some platforms, things like HAVE(READLINE) would be 
>> set correctly by the build system.
>> 
>> Options intended to be set by the environment would carefully be wrapped in 
>> #ifndef.
>> 
>> But other options, which simply express relationships between configuration 
>> elements, are designed to be set by Platform.h and not overridden by the 
>> environment, and so they would not be wrapped in #ifndef. Many HAVE options 
>> and most USE options would fall into this category.
>> 
>> What do you all think?
>> 
>> — Darin
>> ___
>> 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


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


Re: [webkit-dev] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Alexey Proskuryakov

The license is not BSD or LGPL, so that's one aspect to consider.

Why exactly are distros unwilling to update ICU?

- Alexey


> 9 апр. 2020 г., в 10:32 AM, Michael Catanzaro  
> написал(а):
> 
> 
> Any objections to uploading a bundled ICU 60 under Source/ThirdParty?
> 
> Seems easier than forcing downstreams to work out bundling themselves. Most 
> major distros will just stop providing WebKit security updates if we don't 
> bundle it for them. E.g. this is sure to kill Ubuntu's current long streak of 
> providing our updates to Ubuntu 16.04.
> 
> 
> ___
> 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


[webkit-dev] Checking out WebKit source code when using Xcode 11.4

2020-03-24 Thread Alexey Proskuryakov
Hello everyone,

Xcode 11.4 was released today, and it does not include svn or git-svn any more. 
We have posted a standalone installer at  to 
keep getting tools needed for WebKit development easy.

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


Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

2020-03-06 Thread Alexey Proskuryakov


> 6 марта 2020 г., в 18:29, Ryosuke Niwa  написал(а):
> 
> On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  wrote:
>> 
>> Late on Friday seems like a good time for a terminological debate (), so I’d 
>> like to propose we revisit one of the strangest items of WebKit-specific 
>> terminology: the phrase ‘roll out’.
>> 
>> In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
>> ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll 
>> out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to 
>> mean the exact opposite, ‘revert’ or ‘roll back’.
> 
> I think the ship has sailed on this one. People who have been working
> on the WebKit project for long enough are so used to the phrase
> "rollout a patch" that it's gonna be tricky to change the terminology.
> Having said that, I'd much prefer the term "revert" over "rollout" or
> "rollback".

I've been using "roll back" lately, but "revert" seems perfectly fine.

- Alexey

> It's also the term git uses.
>> This term is confusing enough for native English speakers outside our 
>> community, let alone non-natives (since phrasal verbs are notoriously tricky 
>> as it is).
> 
> As a non-native speaker myself, I never find this term confusing
> because I have no mental model of what "rollout" or "rollback" means.
> However, I find those two terms infinitely more confusing than the
> very direct "revert".
> 
> - R. Niwa
> ___
> 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] Clearing old reviews from the queue

2020-02-16 Thread Alexey Proskuryakov


> 16 февр. 2020 г., в 7:52, Dean Jackson  написал(а):
> 
> Does anyone oppose clearing all review requests that are older than 6 months? 
> (or 1 year?)

Looking at ancient patches in the review queue, quite a few look like they 
should still work (e.g. adding new tests). So said that we are not keeping up 
with reviews, even for simple patches.

> I tried to use the bugzilla API to do this, but I couldn't work out how to 
> detect the attachment state properly. I looked at the source code for the 
> queue page and it uses custom SQL :)

What were you trying to do, and how far did you get?

- Alexey

> (It's easy to do with the GitHub API)
> 
> Dean
> 
> ___
> 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] Handling flaky layout-test failures in EWS

2019-12-05 Thread Alexey Proskuryakov


> 5 дек. 2019 г., в 7:58 AM, Aakash Jain  написал(а):
> 
> > What is the current behavior when a patch introduces substantial flakiness?
> 
> For the patch which introduces substantial flakiness (and no consistent 
> failure in EWS), prior to r253049 (which I landed two days back), the patch 
> would be infinitely retried (unless atleast one of the flaky test failed 
> consistently, or the patch is obsolete).
> 
> After r253049, the patch would be marked as passing. EWS is simply not 
> detecting flakiness introduced by a patch (since it doesn't know if the 
> flakiness is introduced by the patch or was pre-existing). However, if any of 
> those 10 tests failed consistently in two runs, the patch would be marked as 
> failing.
> 
> We can work towards improving EWS to better detect flakiness by using data 
> from new flakiness dashboard (which now has the API as well).
> 
> > This looks like decent evidence to make the EWS bubble red.
> We can do that. Have we seen any patch in the past which would fail 5+ tests 
> in first run, and fail completely different 5+ tests in second run? Also, 
> what should be the threshold, should it be 10 (5+5) different test failures 
> (or lower) in two runs?

This would have been difficult to see recently, because EWS just retried when 
hitting this. But I've certainly seen patches that increased flakiness like 
this, so it's a practical case.

Starting with 10 more test failures on two retries (combined) than in a clean 
run seems reasonable.

- Alexey


> Thanks
> Aakash
> 
>> On Dec 3, 2019, at 12:28 PM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> 
>> Yes, I think that this makes more sense than retrying.
>> 
>> What is the current behavior when a patch introduces substantial flakiness? 
>> E.g. this scenario:
>> 
>> - First test run produces 5 failures.
>> - Second test run produces 5 different failures.
>> - Clean re-run produces no failures.
>> 
>> This looks like decent evidence to make the EWS bubble red. I don't know 
>> what exactly the threshold should be, but that should certainly be below 30.
>> 
>> - Alexey
>> 
>> 
>>> 3 дек. 2019 г., в 8:40 AM, Aakash Jain >> <mailto:aakash_j...@apple.com>> написал(а):
>>> 
>>> Hi Everyone,
>>> 
>>> We have various layout-tests which are flaky (which sometimes pass and 
>>> sometimes fail/crash/timeout). EWS needs to work despite these flaky tests, 
>>> and need to be able to tell whether the patch being tested introduced any 
>>> test failure or not.
>>> 
>>> In EWS, we have logic (same logic in both old and new EWS) on how to deal 
>>> with flaky tests. The logic is roughly following:
>>> 
>>> - We apply the patch and build.
>>> 
>>> - Run layout-tests. During the test-run, we retry the failed tests. If 
>>> those tests pass in retry, the run is considered to have no failing test 
>>> (this retry part is same for EWS / build.webkit.org 
>>> <http://build.webkit.org/> / manual-run and part of run-webkit-test script 
>>> itself).
>>> 
>>> - If a test-run has some failures, EWS retry the test-run one more time (to 
>>> check if those test failures were flaky). 
>>> 
>>> - Then we do one more test-run on clean-tree (without the patch), and 
>>> compare the results of first run, second run, and clean tree run.
>>> 
>>> - After that we analyze the results from all three test-runs (which we call 
>>> first_run, second_run and clean_tree_run). 
>>> 
>>> 
>>> If there are different test failures in first and second runs (i.e.: flaky 
>>> test failures), and the patch being tested did not introduce any new test 
>>> failure, we retry the entire build (probably hoping that next time we will 
>>> not see the flakiness). This retry can result in almost infinite loop, if 
>>> someone commits a very flaky test (which is not rare), and would cause EWS 
>>> to be almost stuck until the flakiness is fixed.
>>> 
>>> From 
>>> https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352
>>>  
>>> <https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352>
>>>   ('Defer' means retrying the build).
>>> '''
>>> 350# At this point we know that at least one test flaked, but no 
>>> consistent failures
>>> 351# were introduced. This is a bit of a grey-zone.
>>> 352return False  # 

Re: [webkit-dev] Handling flaky layout-test failures in EWS

2019-12-03 Thread Alexey Proskuryakov

Yes, I think that this makes more sense than retrying.

What is the current behavior when a patch introduces substantial flakiness? 
E.g. this scenario:

- First test run produces 5 failures.
- Second test run produces 5 different failures.
- Clean re-run produces no failures.

This looks like decent evidence to make the EWS bubble red. I don't know what 
exactly the threshold should be, but that should certainly be below 30.

- Alexey


> 3 дек. 2019 г., в 8:40 AM, Aakash Jain  написал(а):
> 
> Hi Everyone,
> 
> We have various layout-tests which are flaky (which sometimes pass and 
> sometimes fail/crash/timeout). EWS needs to work despite these flaky tests, 
> and need to be able to tell whether the patch being tested introduced any 
> test failure or not.
> 
> In EWS, we have logic (same logic in both old and new EWS) on how to deal 
> with flaky tests. The logic is roughly following:
> 
> - We apply the patch and build.
> 
> - Run layout-tests. During the test-run, we retry the failed tests. If those 
> tests pass in retry, the run is considered to have no failing test (this 
> retry part is same for EWS / build.webkit.org / manual-run and part of 
> run-webkit-test script itself).
> 
> - If a test-run has some failures, EWS retry the test-run one more time (to 
> check if those test failures were flaky). 
> 
> - Then we do one more test-run on clean-tree (without the patch), and compare 
> the results of first run, second run, and clean tree run.
> 
> - After that we analyze the results from all three test-runs (which we call 
> first_run, second_run and clean_tree_run). 
> 
> 
> If there are different test failures in first and second runs (i.e.: flaky 
> test failures), and the patch being tested did not introduce any new test 
> failure, we retry the entire build (probably hoping that next time we will 
> not see the flakiness). This retry can result in almost infinite loop, if 
> someone commits a very flaky test (which is not rare), and would cause EWS to 
> be almost stuck until the flakiness is fixed.
> 
> From 
> https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352
>   ('Defer' means retrying the build).
> '''
> 350# At this point we know that at least one test flaked, but no 
> consistent failures
> 351# were introduced. This is a bit of a grey-zone.
> 352return False  # Defer patch
> '''
> 
> 
> Retrying the entire build, just because of few flaky tests seems excessive 
> and inefficient. This doesn't help identify flaky tests, and only delays the 
> EWS result. Instead, we should mark the build as SUCCESS (since the patch did 
> not introduce any new consistent test failure).
> 
> In other EWS test-suites like API tests and JSC tests, we do not retry the 
> entire build on flaky test failures, we ignore the flaky tests, and only 
> focus on tests which failed consistently. We should do the similar thing for 
> layout-tests as well.
> 
> I am going to make that change for layout tests in 
> https://bugs.webkit.org/show_bug.cgi?id=204769. Please let me know if anyone 
> has a different opinion.
> 
> Thanks
> Aakash


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


Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

2019-11-11 Thread Alexey Proskuryakov


> 10 нояб. 2019 г., в 1:16 AM, Noam Rosenthal  написал(а):
> 
> Hola
> 
> I would like to open a discussion that has started a few years back and has 
> never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 
> 
> 
> In a nutshell: content-dpr is a response-only header for images, that allows 
> servers at transient layers (CDNs/proxies) to optimize images by changing 
> their resolution, allowing the user agents to compensate for the change in 
> intrinsic size caused by the resolution change - thus making the resolution 
> change transparent to users. It's the header that makes the 
> resolution-encoding transparent.
> 
> The feature is already up and running in chrome since version 67, and is used 
> by some CDNs.
> 
> Since there was lack of consensus in the bug discussion, I wanted to make the 
> case for it here, and see if opinions about the subject can be voiced before 
> we reach a decision/consensus. I tried to find a good balance between being 
> detailed and being concise. 
> 
> —
> 
> Players in CDN, proxy and other transient parts of the internet world have 
> innovated a lot in the past few years. There are lots of interesting 
> companies and competition there. One of the areas of this innovation is in 
> optimizing images in a transparent way at transient layers (proxy/CDN). This 
> makes a lot of sense considering how much of internet traffic is taken by 
> image download.
> 
> What the research at the CDN companies found, was that modifying resolution 
> at the transient layer can have a tremendous effect on 
> performance/user-experience balance, for example by serving lower-resolution 
> versions of the images when network traffic is costly/slow (the exact formula 
> for that is part of where the CDN can innovate). More details on that 
> innovation in the links below.
> 
> The thing is, that modifying image resolution at the CDN/proxy is not 
> inherently transparent, due to one reason - layout is affected by the image’s 
> intrinsic size, and changing the image’s resolution inadvertently changes the 
> image’s intrinsic size. To make this transparent, the user agent has to be 
> involved, to compensate for this optimization when reading the image’s 
> intrinsic size.
> 
> The main case against this feature was that image resolution is a feature 
> that should be handled at the markup layer and not at the transport layer 
> (https://bugs.webkit.org/show_bug.cgi?id=145380#c7 
> ).
> I would argue that http-headers are not a transport layer (TCP/UDP etc.), but 
> rather part of an application-layer protocol that is designed, in part, to 
> pass information to the transient layers such as CDNs, and that resolution 
> compression is a (new, image-specific) equivalent of transfer-encoding. 
> 
> Also, as a response to the view that this should be part of markup, I would 
> argue that those transparent decisions by the servers should not concern web 
> authors at all. It’s an optimization decision to be handled by the servers, 
> with the user agent doing nothing about it but allow that decision to be 
> transparent in terms of layout (the same way gzip and cache-control are 
> transparent).

I don't see this as a precedent, because cache control and compression are 
invisible to users. Whereas image quality most certainly is. Changing it behind 
both web developer and user back would cause lots of undesirable behaviors - 
say, I e-mail an image from a webpage to someone else, who doesn't have a small 
display, or just zoom in to see the details.

This basically results in the website being untestable by the author (or by UA 
implementers who will be getting bug reports about site behavior differences).

Also, maybe I'm just pessimistic here, but it seems almost inevitable that 
disagreements between markup, Content-DPR and dpi information embedded in 
images will be handled by UAs differently, even if the spec ends up being very 
detailed on this point.

- Alexey


> What is offered here is a win-win in terms of delivering images, and would 
> allow webkit-browser users to enjoy some of the innovations in the image 
> delivery world without modifying their HTML content and without concern of 
> breaking their layouts. Less battery and data used for downloading big images 
> at certain situations, for example.
> 
> I hope this provides enough background without being too tedious. I would be 
> happy to shed more light on whatever is missing in this longish essay :)
> 
> Additional info:
> https://github.com/eeeps/content-dpr-explainer 
> 
> https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67
>  
> 
> https://www.chromestatus.com/metrics/feature/timeline/popularity/906 
> 

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

2019-11-05 Thread Alexey Proskuryakov


> 4 нояб. 2019 г., в 1:37 PM, Ryosuke Niwa  написал(а):
> 
> 
> On Mon, Nov 4, 2019 at 9:40 AM Alexey Proskuryakov  <mailto:a...@webkit.org>> wrote:
> 
> Can you elaborate on that, how exactly is e-mailing on first failure useful 
> to reviewers?
> 
> Getting rid of Bugzilla comments was one of the goals of EWS rewrite, based 
> on engineering feedback about noise in bugs and in e-mail, and I 
> wholeheartedly agree with this feedback. So I think that comments are 
> generally undesirable.
> 
> Since I don't understand what your precise scenario is, I may be make straw 
> man arguments below, but here are some things that I think make the proposed 
> behavior unhelpful (add a comment on first failure, or when all EWSes pass).
> 
> 1. EWS comments in Bugzilla are so annoying that some people take the radical 
> step of manually hiding them. EWS history is archived anyway, there is no 
> need to look into comments for it.
> 
> 2. There are often many people CC'ed on the bug to whom EWS data is 
> irrelevant or even mysterious (e.g. reporters, web developers or 
> non-reviewers). The noise is a slight annoyance, discouraging further 
> participation in the project.
> 
> 3. I believe that for most reviewers, the mode of operation is one of the 
> two: (1) do it when pinged directly, or (2) go over the review queue when one 
> has the time. Getting EWS comments helps neither.
> 
> 4. Commenting when all EWSes pass is not very practical - it's too often that 
> we have some stragglers that take days (or forever). I don't think that we 
> can make it reliable even if we start actively policing EWS responsiveness.
> 
> 5. The reviewer likely wants to know the state of multiple EWSes if they are 
> going to wait for EWS at all. What exactly are they going to do after getting 
> an e-mail that one EWS failed?
> 
> I often use a EWS failure as a signal to wait reviewing a patch. Otherwise, a 
> bug mail will stay in my inbox as one of items to get to.
> 
> I can see the usefulness in the somewhat unusual case of a super urgent 
> patch. We may want multiple people to watch it, so that members of CC list 
> would go and ask the patch author to update it with more urgency than e-mail 
> allows for. I think that opt-in is a better mechanism for that, so that 
> people who opted in would receive information about each EWS data point.
> 
> I think there is a value in knowing that a patch isn't ready instead of 
> having to open the bug to realize that.

So just to clarify, 

- a major part of how you get to review bugs is by being CC'ed, and you review 
them when you have the time to read bugmail;
- and you don't open the bug in Bugzilla if there is already an EWS failure by 
the time you read the e-mail where review is requested?

That's clearly a valid benefit. In my mind, it probably doesn't outweigh the 
downsides. On the other hand, yours is a voice of someone who reviews way more 
patches than Maciej and me combined these days, so maybe more e-mail is an 
overall benefit to many of the reviewers.

- Alexey



> - R. Niwa
>> 3 нояб. 2019 г., в 6:58 PM, Maciej Stachowiak > <mailto:m...@apple.com>> написал(а):
>> 
>> 
>> I think they are useful to actual and potential reviewers. Direct email to 
>> the patch author is not something anyone can Cc themselves on, and is not 
>> archived, so seems like a strictly worse form of communication.
>> 
>>> On Nov 2, 2019, at 9:34 AM, Alexey Proskuryakov >> <mailto:a...@apple.com>> wrote:
>>> 
>>> 
>>> My preference is still e-mailing the patch author directly (possibly, also 
>>> having an option to opt in for anyone). Bugzilla comments will always be 
>>> irrelevant for most people CC'ed on the bug, and they are almost always 
>>> undesirable to keep within the discussion flow.
>>> 
>>> - Alexey
>>> 
>>>> 1 нояб. 2019 г., в 18:28, Aakash Jain >>> <mailto:aakash_j...@apple.com>> написал(а):
>>>> 
>>>> Sounds good. I prefer the single comment when the first failure occur. 
>>>> That way notification would be sent as soon as the first failure happens.
>>>> 
>>>> I'll implement that (assuming it's acceptable to everyone).
>>>> 
>>>> Thanks
>>>> Aakash
>>>> 
>>>>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak >>>> <mailto:m...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> How about only a single comment when the first failure occurs? (Or else 
>>>>> when all bots pass, if there is never a failure.)
>>>>> 
>>>>

Re: [webkit-dev] iOS EWS behind by 3 days??

2019-11-05 Thread Alexey Proskuryakov


> 4 нояб. 2019 г., в 11:30 PM, Ryosuke Niwa  написал(а):
> 
> Hi all,
> 
> Does anyone know what's happening with iOS EWS?

Not yet, but it's part of a cluster of problems related to interactions between 
simulator and specific macOS host versions.

https://bugs.webkit.org/show_bug.cgi?id=203792 tracks this particular issue.

- Alexey


> They're ~3 days behind now:
> https://ews-build.webkit.org/#/builders/24 
> 
> 
> - R. Niwa
> ___
> 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] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

2019-11-04 Thread Alexey Proskuryakov

Can you elaborate on that, how exactly is e-mailing on first failure useful to 
reviewers?

Getting rid of Bugzilla comments was one of the goals of EWS rewrite, based on 
engineering feedback about noise in bugs and in e-mail, and I wholeheartedly 
agree with this feedback. So I think that comments are generally undesirable.

Since I don't understand what your precise scenario is, I may be make straw man 
arguments below, but here are some things that I think make the proposed 
behavior unhelpful (add a comment on first failure, or when all EWSes pass).

1. EWS comments in Bugzilla are so annoying that some people take the radical 
step of manually hiding them. EWS history is archived anyway, there is no need 
to look into comments for it.

2. There are often many people CC'ed on the bug to whom EWS data is irrelevant 
or even mysterious (e.g. reporters, web developers or non-reviewers). The noise 
is a slight annoyance, discouraging further participation in the project.

3. I believe that for most reviewers, the mode of operation is one of the two: 
(1) do it when pinged directly, or (2) go over the review queue when one has 
the time. Getting EWS comments helps neither.

4. Commenting when all EWSes pass is not very practical - it's too often that 
we have some stragglers that take days (or forever). I don't think that we can 
make it reliable even if we start actively policing EWS responsiveness.

5. The reviewer likely wants to know the state of multiple EWSes if they are 
going to wait for EWS at all. What exactly are they going to do after getting 
an e-mail that one EWS failed?

6. More bugmail delays response, especially for active project members who are 
CC'ed on a lot of bugs. I personally started reading bugmail more frequently 
now, knowing that there is more signal and less noise.

I can see the usefulness in the somewhat unusual case of a super urgent patch. 
We may want multiple people to watch it, so that members of CC list would go 
and ask the patch author to update it with more urgency than e-mail allows for. 
I think that opt-in is a better mechanism for that, so that people who opted in 
would receive information about each EWS data point.

- Alexey


> 3 нояб. 2019 г., в 6:58 PM, Maciej Stachowiak  написал(а):
> 
> 
> I think they are useful to actual and potential reviewers. Direct email to 
> the patch author is not something anyone can Cc themselves on, and is not 
> archived, so seems like a strictly worse form of communication.
> 
>> On Nov 2, 2019, at 9:34 AM, Alexey Proskuryakov  wrote:
>> 
>> 
>> My preference is still e-mailing the patch author directly (possibly, also 
>> having an option to opt in for anyone). Bugzilla comments will always be 
>> irrelevant for most people CC'ed on the bug, and they are almost always 
>> undesirable to keep within the discussion flow.
>> 
>> - Alexey
>> 
>>> 1 нояб. 2019 г., в 18:28, Aakash Jain  написал(а):
>>> 
>>> Sounds good. I prefer the single comment when the first failure occur. That 
>>> way notification would be sent as soon as the first failure happens.
>>> 
>>> I'll implement that (assuming it's acceptable to everyone).
>>> 
>>> Thanks
>>> Aakash
>>> 
>>>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak  wrote:
>>>> 
>>>> 
>>>> How about only a single comment when the first failure occurs? (Or else 
>>>> when all bots pass, if there is never a failure.)
>>>> 
>>>> This should help the author, the reviewer, and anyone else cc’d, without 
>>>> being too spammy.
>>>> 
>>>>> On Nov 1, 2019, at 5:20 PM, Aakash Jain  wrote:
>>>>> 
>>>>> Hi Ryosuke,
>>>>> 
>>>>> Many people didn't like the noise by the EWS comments, and we removed the 
>>>>> comments as per previous discussion in: 
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2019-June/030683.html.
>>>>> 
>>>>> I agree with your point that having some kind of notification might be 
>>>>> useful.
>>>>> 
>>>>> I proposed some ideas in 
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030798.html, 
>>>>> but didn't get much feedback. If we can all agree on a solution, I can 
>>>>> look into implementing it.
>>>>> 
>>>>> Thanks
>>>>> Aakash
>>>>> 
>>>>>> On Oct 30, 2019, at 1:03 AM, Ryosuke Niwa  wrote:
>>>>>> 
>>>>>> These enhancements are great. There is one feature of the old EWS that I 
>>>>>> really miss, which is that I used to ge

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

2019-11-02 Thread Alexey Proskuryakov
My preference is still e-mailing the patch author directly (possibly, also 
having an option to opt in for anyone). Bugzilla comments will always be 
irrelevant for most people CC'ed on the bug, and they are almost always 
undesirable to keep within the discussion flow.

- Alexey

> 1 нояб. 2019 г., в 18:28, Aakash Jain  написал(а):
> 
> Sounds good. I prefer the single comment when the first failure occur. That 
> way notification would be sent as soon as the first failure happens.
> 
> I'll implement that (assuming it's acceptable to everyone).
> 
> Thanks
> Aakash
> 
>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak  wrote:
>> 
>> 
>> How about only a single comment when the first failure occurs? (Or else when 
>> all bots pass, if there is never a failure.)
>> 
>> This should help the author, the reviewer, and anyone else cc’d, without 
>> being too spammy.
>> 
>>> On Nov 1, 2019, at 5:20 PM, Aakash Jain  wrote:
>>> 
>>> Hi Ryosuke,
>>> 
>>> Many people didn't like the noise by the EWS comments, and we removed the 
>>> comments as per previous discussion in: 
>>> https://lists.webkit.org/pipermail/webkit-dev/2019-June/030683.html.
>>> 
>>> I agree with your point that having some kind of notification might be 
>>> useful.
>>> 
>>> I proposed some ideas in 
>>> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030798.html, 
>>> but didn't get much feedback. If we can all agree on a solution, I can look 
>>> into implementing it.
>>> 
>>> Thanks
>>> Aakash
>>> 
 On Oct 30, 2019, at 1:03 AM, Ryosuke Niwa  wrote:
 
 These enhancements are great. There is one feature of the old EWS that I 
 really miss, which is that I used to get emails when some EWS failed. With 
 new EWS, I have to keep checking back the bugzilla to see if any of them 
 have failed periodically.
 
 Can we add a feature to opt into such an email notification? Maybe a flag 
 on a patch or JSON configuration file somewhere.
 
 - R. Niwa
 
 On Tue, Oct 29, 2019 at 4:05 PM Aakash Jain  wrote:
 Hi Everyone,
 
 I am happy to announce another EWS feature.
 
 From now on, in case of build failure, EWS will parse the errors and 
 display them in a separate 'errors' log. You wouldn't have to search 
 through thousands of lines of logs to find the error message.
 
 For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, in 
 step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+ lines, 
 and the error is not at the end of the logs. Normally, it requires some 
 searching through the logs to find the relevant errors. But now, there is 
 another 'errors' log, which contains just the relevant 11 lines 
 (containing error and few related lines to provide additional context).
 
 Hopefully this would save some time and efforts previously spent on 
 searching through the large logs.
 
 Note that this information is not displayed in status-bubble tool-tip, 
 since this might be lot of text to display in the tooltip. My further plan 
 is to make this information more readily available, by adding it to a 
 custom designed page which will open on clicking the status bubble 
 https://webkit.org/b/197522
 
 Please let me know if you notice any issues or have any feedback.
 
 Thanks
 Aakash
 
 Reference: https://webkit.org/b/203418
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 -- 
 - R. Niwa
>>> 
>>> ___
>>> 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

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


Re: [webkit-dev] 2019 WebKit Contributors Meeting - Hurry! Registration is Closing!

2019-10-25 Thread Alexey Proskuryakov

Seems like an issue to look into. However this should not prevent you from 
registering, because you do have a Trac account (it's the same thing as your 
svn account).

- Alexey


> 25 окт. 2019 г., в 8:07 AM, Geoffrey Garen  написал(а):
> 
> The Login page looks like this:
> 
> 
> 
> If you click the  link, it takes you to 
> https://webkit.org/auth/wregister . 
> 
> I’m not sure what “not used for registration this year means”; but what I 
> mean is that this link is present on the page, and clicking it loads an error 
> page.
> 
> Thanks,
> Geoff
> 
>> On Oct 24, 2019, at 11:11 PM, Ling Ho > > wrote:
>> 
>> Hi Geoff,
>> 
>> Please go to https://webkit.org/auth/wlogout/ 
>>  and make sure you are not logged in. Then 
>> go to https://www.webkit.org/meeting  and 
>> make sure the pages says "2019 WebKit Contributors Meeting". After that, try 
>> logging in and register again. The "https://webkit.org/auth/wregister 
>> " is not used for registration this year.
>> 
>> ...
>> ling
>> 
>> On 10/24/19 9:12 PM, Geoffrey Garen wrote:
>>> https://webkit.org/auth/wregister 
>>> 
>>> Internal Server Error
>>> 
>>> The server encountered an internal error or misconfiguration and was unable 
>>> to complete your request.
>>> 
>>> Please contact the server administrator at ad...@webkit.org 
>>>  to inform them of the time this error occurred, 
>>> and the actions you performed just before this error.
>>> 
>>> More information about this error may be available in the server error log.
>>> 
>>> 
 On Oct 23, 2019, at 4:06 PM, Jonathan Davis >>> > wrote:
 
 Hello WebKit Contributors,
 
 This is a short reminder that your chance to register to attend the WebKit 
 Contributors Meeting is closing after Friday, October 25th!
 
 Please be sure you’ve registered for the meeting at 
 https://webkit.org/meeting/ 
 
 The schedule of topics is filling in, but there are still a couple of 
 larger time slots available. If you have a topic you’d like to present for 
 discussion, please send me an email to secure a spot on the schedule.
 
 Note that the longer prepared talks are anywhere between 30-40 minutes 
 leaving time for questions and discussions before the next session. If you 
 have a short topic to present, email me about giving a 5-10 minute 
 lightning talk.
 
 See you next Friday!
 
 Jon Davis
 
> On Sep 18, 2019, at 1:47 PM, Jonathan Davis  > wrote:
> 
> Hello WebKit Contributors,
> 
> You are invited to attend the annual WebKit Contributors Meeting to be 
> held at the Hilton Santa Clara hotel on Friday, November 1st, 2019 from 8 
> AM to 6 PM Pacific.
> 
> Breakfast and sign-in will begin at 8 AM. Presentations will run between 
> 9 AM to 6 PM. Lunch will be provided with all day coffee, tea and a 
> mid-afternoon snack break. A reception is planned at the venue after the 
> meeting with dinner and drinks from 6 PM to 9 PM.
> 
> To attend you must be an active WebKit contributor. The meeting will be 
> free of charge, and registration is open. Register at 
> https://webkit.org/meeting/  
> 
> The event format will include a mix of prepared talks around 40 minutes 
> long with 10-15 minutes of questions, and spontaneous lightning talks 
> about 5-10 minutes long. If you have a topic idea that you want to 
> present, please email me directly.
> 
> We look forward to seeing you there!
> 
> Thank you,
> Jon Davis
 
 ___
 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 
>>> 
>> 
> 
> ___
> 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] Moving to Python 3

2019-07-16 Thread Alexey Proskuryakov


> 15 июля 2019 г., в 23:04, Fujii Hironori  
> написал(а):
> 
> 
> On Sun, Jul 14, 2019 at 7:44 AM Ryosuke Niwa  > wrote:
> 
> I don’t think anyone is arguing that we’d eventually need to move to Python3. 
> I’m arguing that it’s not okay to require random WebKit contributor to know 
> some obscure python insanity to install Python 3, or have a script that 
> installs Python 3 and breaks all other python scripts in the system.
> 
> 
>  Just out of curiosity. As far as I know, installing Python 3 breaks nothing. 
> What and why are they got broken?

As always, it will be up to the people doing the work to decide how it's done. 
The feedback is clear:

- They shouldn't make it excessively difficult to do WebKit engineering on 
older versions of macOS.

"Excessively" is not clearly defined, but it seems obvious that there is a 
tradeoff between tools work difficulty, and difficulty for engineers who go 
back to older macOS versions (and implicitly, difficulty for people who set up 
bots, QA engineers, and others involved).

I don't think that anyone ever suggested that it will be up to each engineer to 
figure out the best way to install Python 3.

- virtualenv works great for some projects.

Definitely worth looking at it as one of the primary paths forward. It's not 
just Python itself, but we don't want to pollute the system with modules 
either. Although the latter already has a pretty nice solution in WebKit with 
autoinstall.

- virtualenv shouldn't be required when building WebKit, and dynamic 
dependencies in general are not OK in this scenario.

- Alexey

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


Re: [webkit-dev] Changing the svn commit hook to allow tabs for tests.

2019-05-10 Thread Alexey Proskuryakov

> 10 мая 2019 г., в 13:50, Darin Adler  написал(а):
> 
>> On May 10, 2019, at 1:13 PM, Keith Miller  wrote:
>> 
>> I’m not sure I know what you mean by allow a whole-directory exception. Do 
>> you mean a top level directory? Or some kind of parameter we pass to the 
>> hook to ignore some directory for that run?
> 
> I meant that we could add something the pre-commit hook could see in 
> Subversion that would create an exception for a whole directory, rather than 
> something inside the hook itself. Perhaps a specially named file, or a 
> Subversion attribute on a specially named file, or something more clever. If 
> Subversion had attributes on directories, it could be that.

Subversion supports properties on directories, we use those for svn:ignore as 
an example. It is correct that the pre-commit hook doesn't currently check 
parent directory properties.

An alternative is to just set it on all files in the directory.

>> you can’t commit with git-svn as it doesn’t support svn properties (or at 
>> least I wasn’t able to figure it out)
> 
> Ah, that’s a big blocker if lots of people are using git-svn — I certainly 
> use it.

Looks like it may now work with recent versions of git (as in since 2015), 
https://stackoverflow.com/questions/1271449/how-to-set-subversion-properties-with-git-svn
 :

git-svn: support for git-svn propset

This change allows git-svn to support setting subversion properties.

It is useful for manually setting properties when committing to a subversion 
repo that requiresproperties to be set without requiring moving your changeset 
to separate subversion checkout in order to set props.

There is a nit to point out: the code does not support adding props unless 
there are also content changes to the files as well.
This is demonstrated in the testcase.

- Alexey

> — Darin
> ___
> 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] Spam and indexing

2019-05-02 Thread Alexey Proskuryakov

I posted a tool that I used for this today to 
https://bugs.webkit.org/show_bug.cgi?id=197537. Probably a lot to improve, but 
it works.

- Alexey


> 2 мая 2019 г., в 14:32, Darin Adler  написал(а):
> 
> Should we post instructions somewhere for people dealing with spam? I believe 
> the instructions are:
> 
> 1) Look up the email address of the account that posted the spam and disable 
> it first, so spammers don’t get email about other steps. Do this by clicking 
> on Administration, Users, finding the user and putting the word “Spam” into 
> the disable text.
> 
> 2) Move any spam bugs into the Spam component.
> 
> 3) Mark any spam comments as Private and also add the tag “spam”.
> 
> But maybe there’s more to it than that. For example, can someone without 
> administration privileges do the right thing? Should we make a small tool to 
> make this easier to do correctly?
> 
> I like the idea of having instructions so this isn’t oral tradition.
> 
> — Darin


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


Re: [webkit-dev] Spam and indexing

2019-05-02 Thread Alexey Proskuryakov

One change that I'm going to make is to mark spam comments as private instead 
of simply tagging. That way, bugs will look cleaner, and there will be no doubt 
about whether search engines index hidden comments or not.

I'll also mark old spam comments as private. I think that this will generate 
e-mail notifications, so apologies for the upcoming e-mail storm. These should 
be possible to delete all at once in most e-mail clients.

- Alexey

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


Re: [webkit-dev] Spam and indexing

2019-03-29 Thread Alexey Proskuryakov


> 28 марта 2019 г., в 14:10, Konstantin Tokarev  написал(а):
> 
> 
> 
> 28.03.2019, 23:58, "Alexey Proskuryakov" :
>> Hello,
>> 
>> The robots.txt file that we have on bugs.webkit.org currently allows search 
>> engines access to individual bug pages, but not to any bug lists. As a 
>> result, search engines and the Internet Archive only index bugs that were 
>> filed before robots.txt changes a few years ago, and bugs that are directly 
>> linked from webpages elsewhere. These bugs are where most spam content 
>> naturally ends up on.
>> 
>> This is quite wrong, as indexing just a subset of bugs is not beneficial to 
>> anyone other than spammers. So we can go in either direction:
>> 
>> 1. Allow indexers to enumerate bugs, thus indexing all of them.
>> 
>> Seems reasonable that people should be able to find bugs using search 
>> engines.
> 
> Yes, and it may give better result even than searching bugzilla directly
> 
>> On the other hand, we'll need to do something to ensure that indexers don't 
>> destroy Bugzilla performance,
> 
> This can be solved by caching

Is this something that other Bugzilla instances do? I'm actually not sure how 
caching can be meaningfully applied to Bugzilla. One wants to always see the 
latest updates, and our automation in particular won't be OK with stale data.

- Alexey

>> and of course spammers will love having more flexibility.
> 
> rel="nofollow" on all links in comments should be enough to make spamming 
> useless
> 
>> 
>> 2. Block indexing completely.
>> 
>> Seems like no one was bothered by lack of indexing on new bugs so far.
> 
> That's survival bias - if nobody can find relevant bugs, nobody will ever 
> complain
> 
>> 
>> Thoughts?
>> 
>> For reference, here is the current robots.txt content:
>> 
>> $ curl https://bugs.webkit.org/robots.txt
>> User-agent: *
>> Allow: /index.cgi
>> Allow: /show_bug.cgi
>> Disallow: /
>> Crawl-delay: 20
>> 
>> - Alexey
>> - Alexey
>> 
>> ___
>> 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


[webkit-dev] Spam and indexing

2019-03-28 Thread Alexey Proskuryakov
Hello,

The robots.txt file that we have on bugs.webkit.org currently allows search 
engines access to individual bug pages, but not to any bug lists. As a result, 
search engines and the Internet Archive only index bugs that were filed before 
robots.txt changes a few years ago, and bugs that are directly linked from 
webpages elsewhere. These bugs are where most spam content naturally ends up on.

This is quite wrong, as indexing just a subset of bugs is not beneficial to 
anyone other than spammers. So we can go in either direction:

1. Allow indexers to enumerate bugs, thus indexing all of them.

Seems reasonable that people should be able to find bugs using search engines. 
On the other hand, we'll need to do something to ensure that indexers don't 
destroy Bugzilla performance, and of course spammers will love having more 
flexibility.

2. Block indexing completely.

Seems like no one was bothered by lack of indexing on new bugs so far.

Thoughts?


For reference, here is the current robots.txt content:

$ curl https://bugs.webkit.org/robots.txt
User-agent: *
Allow: /index.cgi
Allow: /show_bug.cgi
Disallow: /
Crawl-delay: 20

- Alexey
- Alexey


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


[webkit-dev] WebCorePrefix.h vs. config.h

2018-12-07 Thread Alexey Proskuryakov
Hi,

Do we still need separate WebCorePrefix.h and config.h? The former has this 
comment, which I don't think is true any more:

/* This prefix file should contain only:
 *1) files to precompile for faster builds
 *2) in one case at least: OS-X-specific performance bug workarounds
 *3) the special trick to catch us using new or delete without including 
"config.h"
 * The project should be able to build without this header, although we rarely 
test that.
 */

/* Things that need to be defined globally should go into "config.h". */

There are many things that contradict this comment in this file. And even when 
precompiled header is not in use, we include WebCorePrefix.h from config.h 
anyway:

// Using CMake with Unix makefiles does not use prefix headers.
#if PLATFORM(MAC) && defined(BUILDING_WITH_CMAKE)
#include "WebCorePrefix.h"
#endif

I'm mostly looking at some HAVE and ENABLE macros that are in these and should 
be elsewhere, but the confusion between these files bothers me a lot. Should we 
move everything from config.h to WebCorePrefix.h, and only keep config.h just 
to include WebCorePrefix for the lone build scenario where that's needed, and 
to undef new/delete?

- Alexey

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


Re: [webkit-dev] Lots of spam on Bugzilla

2018-12-04 Thread Alexey Proskuryakov


> 4 дек. 2018 г., в 16:45, Ryosuke Niwa  написал(а):
> 
> Alternatively, is there a way you can make more of us be able to moderate 
> these spammers?


Anyone can tag comments to make them invisible, but there is no privilege level 
in Bugzilla where one can disable user accounts, but cannot grant full admin 
privileges.

- Alexey

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


Re: [webkit-dev] Proposal for Device-Specific Layout Tests

2018-12-04 Thread Alexey Proskuryakov


> 4 дек. 2018 г., в 16:43, Ryosuke Niwa  написал(а):
> 
> 
> On Tue, Dec 4, 2018 at 12:55 PM Jonathan Bedard  > wrote:
> These directories would be along-side tests.
> 
> I don't like that platform-specific results are under LayoutTests/platform 
> and device-specific results are next to the tests. We should stick with 
> either convention, not mix them up.
> 
> If we were to match LayoutTests/platforms, we should probably put it under 
> LayoutTests/devices, or alternatively inside each platform's test directory. 
> Alternatively, I'd be fine if we moved platform specific results to those 
> subdirectories. But having both conventions used throughout would be an 
> insane mess.

I'm not ready to have an opinion about which approach is best, however I wanted 
to make a general comment about unification.

I think that the attempt to abstract all sorts of differences behind the "port" 
and "platform" concepts in webkitpy was short sighted. There are many subtle 
and not so subtle variations of behaviors (OS, OS family, specific OS version, 
build style, specific API used from the build when there are multiple options). 
Trying to represent these by god objects is creating a lot more inconsistency 
and confusion than necessary.

One good thing about platform directories is that we can specify inheritance 
order with these in a way that is somewhat meaningful. If we are to have an 
inheritance order for device types, then continuing with the approach would 
make sense. But if the rule is exact match, or best match, then storing them as 
-expected directories makes good sense to me.

- Alexey

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


Re: [webkit-dev] Lots of spam on Bugzilla

2018-12-04 Thread Alexey Proskuryakov

> 4 дек. 2018 г., в 11:21, Ryosuke Niwa  написал(а):
> 
> e.g.
> https://bugs.webkit.org/show_bug.cgi?id=168774 
> 
> 
> Is there a way we can integrate CAPTCHA, etc... to prevent these spammers 
> from getting Bugzilla account?

We can integrate CAPTCHA, but based on how the spammers operate, it seems 
unlikely that it would help much. As far as we could find, other Bugzilla 
instances haven't solved this either.

Many of the spam comments look like they were written by humans who skimmed the 
comments above, and there were a couple where the comments looked quite 
convincing at first glance. And the registration process includes sending a 
confirmation link to their e-mail account, which is Gmail most of the time. So 
it's already taking more dedication than passing a CAPTCHA would require.

What I would want to know is what lures spammers to bugzilla. Perhaps we can 
find a way to decrease bugs.webkit.org page rank or whatever makes it a 
valuable target.

- Alexey


> - R. Niwa
> ___
> 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] Design for review: EWS for security bugs

2018-06-20 Thread Alexey Proskuryakov


> 16 июня 2018 г., в 0:12, Daniel Bates  написал(а):
> 
> Hi all,
> 
> I am working to support EWS processing of patches on security bugs (see 
>  >) and I am writing to this 
> list to solicit feedback on any show-stopper bugs in the proposed design. 
> Historically we have not supported this functionality because the EWS was 
> designed to use Bugzilla as its data store and hence the EWS machines 
> (considered untrusted) would need a Bugzilla account with access to all 
> security bugs. Here is my idea to solve this problem without privileging 
> these machines with full security bug access:
> 
> Have webkit-queues.webkit.org  host copies 
> of security sensitive patches. These patches will be deleted once all EWS 
> queues have processed them. Access to these patches will be guarded by an API 
> key(s) to prevent anonymous access. Each EWS machine will need one. 
> Otherwise, it will skip such patches.
> The tool webkit-patch will now upload a copy of each patch attached to a 
> security bug to webkit-queues.webkit.org  
> as part of submitting a patch to EWS.
> Add a Bugzilla extension to CC the EWS feeder queue on a bug if it has a 
> patch up for review, including security bugs. (The EWS feeder queue is 
> responsible for polling Bugzilla to find unreviewed patches and submitting 
> them to webkit-queues.webkit.org ).
> The EWS feeder queue will now upload a copy of each patch attached to a 
> security bug to webkit-queues.webkit.org  
> as part of submitting a patch to EWS.
> 
> Then EWS machines will be able to process security sensitive patches, report 
> compile-time errors and the list of failing tests. There are three known 
> issues with this approach: 1) EWS bots cannot comment on security bugs 2) EWS 
> bots cannot upload layout test failure tarballs to security bugs and 3) the 
> "Submit for EWS analysis" button will not work. I plan to solve these issues 
> in subsequent bugs. One way to solve the first two issues is to have 
> webkit-queues.webkit.org  store comments 
> and tarballs and teach the EWS feeder queue (or another bot) to submit these 
> comments and upload these tarballs to Bugzilla on behalf of the EWS bots 
> (since the EWS feeder queue has access to the security bug by design decision 
> (3)). To solve the last issue without requiring a person to re-enter their 
> Bugzilla credentials there are at least three approaches: 1) set an 
> appropriate CORS policy for webkit-queues.webkit.org 
>  to access Bugzilla 2) 
> webkit-queues.webkit.org  asks Bugzilla to 
> POST a form back to it or 3) re-implement and host the "Submit for EWS 
> analysis" button on Bugzilla so that it can upload the security sensitive 
> patch to EWS when clicked then redirect to the status-bubbles page on 
> webkit-queues.webkit.org .

I just have a comment about the known issues. Not sure if it makes sense to 
invest effort into addressing these within current design, as we want to stop 
using custom EWS code and move as much as possible to Buildbot.

The stack that EWS is currently built on is very different from anything else 
we use, so it's difficult to maintain.

- Alexey

> I am open to suggestions.
> 
> Dan
> ___
> 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] Trying to builder older version of webkit (but failing) - looking for help

2018-05-22 Thread Alexey Proskuryakov
Hello Ted,

603.1.30 is the version included with Safari 10.1 on Sierra, so yes, building 
it against High Sierra SDK with newer Xcode puts you on uncharted territory. 
The file that you are hitting an issue with is one of the first files in 
WebCore to build, so chances are that there will be many other build issues 
later on.

Getting an older macOS version to debug with would likely be a more practical 
approach.

- Alexey

> 22 мая 2018 г., в 3:35, Ted Stresen-Reuter  написал(а):
> 
> (also posted in IRC, but I prefer email)
> 
> Hi. My name is Ted. I am a web application developer. I've got a site done 
> using CSS Grid. Version 10.1.2 (12603.3.8) of Safari has a small issue 
> rendering one page because we didn't explicitly specify grid-template-rows.
> 
> Normally we use browserstack for fixing these types of issues but in this 
> case the page in question is a long and somewhat complex form and it's 
> difficult to debug via browserstack. I found this stackoverflow question that 
> suggests a method for running an older version of Safari but some of the 
> links are now broken.
> 
> https://stackoverflow.com/questions/33423269/is-there-a-way-to-install-emulate-an-older-version-of-safari-i-e-8
>  
> 
> 
> I decided to try building Safari / webkit on a tag that seemed to be roughly 
> the version I needed based on the stackoverflow answer but the build is 
> failing :-(
> 
> I can build other software (AppleScript projects I've worked on and some 
> React Native projects) but webkit just isn't building.
> 
> I am trying to build this exact tag: 
> https://svn.webkit.org/repository/webkit/tags/Safari-603.1.30/ 
> 
> 
> The error I'm getting is:
> 
> The following build commands failed: CompileC {long path reduced for 
> legibility}/AccessibilityImageMapLink.o 
> accessibility/AccessibilityImageMapLink.cpp normal x86_64 c++ 
> com.apple.compilers.llvm.clang.1_0.compiler
> 
> I'm wondering if this version simply won't compile on High Sierra or if I 
> need a specific version of the XCode Cocoa SDK… My XCode version is Version 
> 9.2 (9C40b) 
> 
> No idea… Any pointers would be greatly appreciated.
> 
> Thanks and very kind regards.
> 
> -- 
> Ted Stresen-Reuter
> 
> [t...@secret-source.eu ]
> 
> tel ES: +34 928359902 
> tel UK: +44 (0)2071933739
> Skype: t...@secret-source.eu 
> 
> secret-source.eu 
> 
> Like to know more about us? Check out our promo video: 
> https://vimeo.com/167722524 
> 
> *For out of hours support please email outofho...@secret-source.eu 
>  as my email is only monitored 9-5 Monday 
> toFriday*
> ___
> 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] Request for upgrading xcode toolchains in Apple bots for C++17

2018-05-21 Thread Alexey Proskuryakov
Hi,

To clarify, are you asking specifically for mac-32bit EWS to be upgraded? It 
has Xcode 9.2, and can be upgraded to 9.3.1 (that will be a multi-step process, 
as we need to keep the version in sync with several other setups). But macOS 
Sierra bots have Xcode 8.3.3, and that is the latest release for Sierra.

- Alexey


> 21 мая 2018 г., в 6:44, Yusuke SUZUKI  написал(а):
> 
> Hi WebKittens, in particular Apple bot maintainers!
> 
> We are about to enable C++17 in all the WebKit ports, and the last step is 
> enabling C++17 for Xcode[1].
> While the latest shipped Xcode (w/ clang) supports C++17 option 
> (`-std=gnu++17`), EWS build bots do not support this. Some build bots accept 
> `-std=c++1z`, this option causes trouble in the latest Xcode (e.g. mac-32bit 
> uses the newer Xcode).
> 
> Can we upgrade Xcodes in EWS and buildbots to the latest ones to accept C++17 
> option? Once it is done, WebKit starts using fancy C++17 features listed in 
> GCC 6.0.
> 
> Best regards,
> Yusuke Suzuki
> 
> [1]: https://bugs.webkit.org/show_bug.cgi?id=185176 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Alexey



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


Re: [webkit-dev] Test262 includes some tab characters

2018-02-04 Thread Alexey Proskuryakov

> 4 февр. 2018 г., в 7:09, Yusuke SUZUKI  написал(а):
> 
> Hi WebKittens,
> 
> Recently, I updated test262, and I found newly added test262 files include 
> TAB characters (\t).
> IIRC, I need some help to import such files into WebKit tree.
> Can we make JSTests/test262 directory free from any SVN style checks?

Yes, one can add an allow-tabs property to bypass the check in pre-commit hook. 
This can be part of the patch.

- Alexey

> Best regards,
> Yusuke Suzuki
> ___
> 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] Hosting precompiled `jsc` binaries for Linux

2017-12-12 Thread Alexey Proskuryakov

> 12 дек. 2017 г., в 10:58, Mathias Bynens <m...@google.com> написал(а):
> 
> Yes, there is such an expectation. jsvu has a policy of only using URLs “that 
> are controlled by the creators of the JavaScript engine”: 
> https://github.com/GoogleChromeLabs/jsvu#security-considerations 
> <https://github.com/GoogleChromeLabs/jsvu#security-considerations>
This is explained as a security policy. If the project considers Igalia builds 
unsafe, how are the same bits copied to another domain by an automated process 
any better?

I'm not necessarily objecting against the copying, but trying to make a 
legitimate story for why any extra work is needed.

- Alexey


> Anything not on *.webkit.org <http://webkit.org/> or similar, or anything not 
> on on S2 buckets that are owned by Apple directly, does not fit that policy.
> 
> On Tue, Dec 12, 2017 at 7:35 PM, Alexey Proskuryakov <a...@webkit.org 
> <mailto:a...@webkit.org>> wrote:
> 
>> 12 дек. 2017 г., в 1:34, Mathias Bynens <m...@google.com 
>> <mailto:m...@google.com>> написал(а):
>> 
>> It would be great to make such downloads available from webkit.org 
>> <http://webkit.org/> or
>> a similar domain!
> 
> 
> Can you explain in more detail why this is important?
> 
> If there is an expectation that this will make the builds more official in 
> some way, then I'd like to understand the difference better. For example, 
> will having links to igalia.com <http://igalia.com/> on webkit.org 
> <http://webkit.org/> work just as well?
> 
> - Alexey
> 
> 


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


Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-12 Thread Alexey Proskuryakov

> 12 дек. 2017 г., в 1:34, Mathias Bynens  написал(а):
> 
> It would be great to make such downloads available from webkit.org 
>  or
> a similar domain!


Can you explain in more detail why this is important?

If there is an expectation that this will make the builds more official in some 
way, then I'd like to understand the difference better. For example, will 
having links to igalia.com on webkit.org work just as well?

- Alexey

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


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-28 Thread Alexey Proskuryakov

> 17 нояб. 2017 г., в 23:02, youenn fablet  написал(а):
> 
> Tests are available at https://w3c-test.org  which 
> makes it easy to share through any tool supporting hyperlinks.
> A webarchive can also be made so that it is easy to share and probably edit 
> such tests.
> Tools like jsfiddle are also a great way to create/share/edit tests.
> I received several bug reports on bugzilla using it and this proved to be 
> efficient.

I don't think that these are applicable verbatim, but there may be some 
solution. Let's find it before assuming that we can have it.

In particular, 
- editing a WebArchive is not really feasible;
- jsfiddle is cool, but I can't just copy a WPT test to jsfiddle to share it.

> Let me explain why I think that WebKit tests are often more valuable as 
> regression tests than WPT tests are. We add tests as we fix bugs, so we know 
> that the tests are generally for problems that have a high impact on users 
> and developers - that's because someone actually discovered the problem, and 
> someone prioritized it highly enough to fix. We also know that our tests 
> cover code that is error prone, which is why we had bugs in the first place. 
> Of course, anything can be broken, but certain things are less likely to. 
> Compliance tests written for specs are also valuable, but at some point we 
> need to prioritize which tests to investigate and even to run.
>  
> I don't really see why we should prioritize the tests to run when all of them 
> provide clear value to some WebKit members.

We prioritize which tests to run all the time, there are whole configurations 
for which we don't run any tests. That's largely because it's not enough to 
simply run the tests - keeping them in a state where they produce actionable 
results requires a lot of attention.

The time it takes to run tests definitely matters a lot for WebKit. So far we 
haven't taken a route like the one Robert mentioned, with a huge amount of 
hardware running shards of tests. There are multiple reasons to that, one of 
those being that we are very interested in finding bugs below WebKit too, and 
having dedicated testers helps with that. When the machine gets into a weird 
state after a few weeks of uptime, it is much easier to start isolating the 
problem when we can see which specific queues are hitting it. It is also much 
easier to reason about data collected by centralized systems, such as crash log 
collection services.

- Alexey


> I agree that we need to prioritize tests we investigate. There can be a 
> solution inside WPT, like adding WebKit specific metadata so that:
> - WPT contributors would communicate with WebKit members whenever changing 
> such tests
> - WebKit contributors would prioritize WPT-WebKit-metadata failing tests
> 
> That said, if these tests are so beneficial to WebKit, they are potentially 
> very useful to other teams as well.
> And vice-versa, we might find really good WPT tests that show useful crashes 
> and failures in WebKit.
> I am experiencing that nowadays with WPT service worker tests.


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


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-17 Thread Alexey Proskuryakov
(re-sending from a correct address)

> 17 нояб. 2017 г., в 9:18, youenn fablet  > написал(а):
> 
> Chris recently noticed that some heavily used files (testharness*) were 
> cacheable through Apache but not WPT.
> This is now fixed and should improve WPT performances.

This is part of >, another part is that the 
server is 10x slower than Apache.

I just tested on my MacBook Pro, and WPT tests took 23% of time while being 
only 9% of the total count. Taking in mind that WebKit own tests have higher 
value due to the way we choose what to test (see below), that's not a great 
story in my opinion.

One other thing that we discussed before was the operational complexity of 
running WPT tests. We frequently need to share tests with people who don't work 
on WebKit directly, but have the need to edit and run our tests. Inability to 
drag and drop a local copy into a Safari window is a deterrent to addressing 
problems caught by the tests. I think that the response we got was that tests 
will continue to require a server to run.

Let me explain why I think that WebKit tests are often more valuable as 
regression tests than WPT tests are. We add tests as we fix bugs, so we know 
that the tests are generally for problems that have a high impact on users and 
developers - that's because someone actually discovered the problem, and 
someone prioritized it highly enough to fix. We also know that our tests cover 
code that is error prone, which is why we had bugs in the first place. Of 
course, anything can be broken, but certain things are less likely to. 
Compliance tests written for specs are also valuable, but at some point we need 
to prioritize which tests to investigate and even to run.

- Alexey

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


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-16 Thread Alexey Proskuryakov

Migrating WebKit tests seems undesirable to me, as that would make us lose all 
their modification history. As mentioned before, WPT tests are inherently 
getting less attention in CI support, largely because of unclear benefit when 
there isn't any history for why the particular test was added.

Regression tests are taking an excessive amount of time to run for us (more 
than 1.5 hours in a debug build), a very large proportion of which is WPT. I do 
not think that the strategy of adopting WPT tests is working well for WebKit.

- Alexey


> 15 нояб. 2017 г., в 2:02, Philip Jägenstedt  написал(а):
> 
> Hello webkit-dev! (ecosystem-infra in Bcc)
> 
> TPAC was last week, and there was much talk about web-platform-tests. Some 
> notes are at 
> https://lists.w3.org/Archives/Public/public-test-infra/2017OctDec/thread.html 
> 
>  and in particular https://www.w3.org/2017/11/07-testing-minutes.html 
> .
> 
> In Blink, we're thinking seriously about what it'd take to upstream large 
> parts of LayoutTests into web-platform-tests, and we've realized that there 
> are some risks here, beyond just making sure the tests are good and per spec. 
> Specifically, one bad outcome would be if Blink successfully upstreamed 
> thousands of tests that are also in WebKit, which then begin to diverge in 
> small and large ways. That'd leave WebKit with more duplication between its 
> own tests and web-platform-tests than any other engine, and a headache that 
> grows over time.
> 
> So, I think this would require close cooperation with the WebKit project. 
> Some different ways this might happen:
> A Blink developer and WebKit developer work together at the same time to move 
> their common tests in some area into web-platform-tests, each removing 
> identical tests that were upstreamed by the other and consolidating what 
> remains.
> A Blink developer works to first upstream tests from WebKit (using WebKit's 
> coming export mechanism), waits for it to be imported into Blink, and then 
> removes the tests from Blink.
> The reverse situation.
> 
> Are there already some areas where the first approach might be doable, where 
> the Blink and WebKit folks already know each other and are eager to do this? 
> Is LayoutTests/css3/flexbox/ by any chance such a case?
> 
> I realize it's hard to judge these approaches in the abstract, but am curious 
> to hear any enthusiasm or concerns about it.
> 
> Thanks!
> ___
> 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] Dead code in webkitpy runtests.py

2017-11-01 Thread Alexey Proskuryakov

I think that we would still like to have a unified way to run tests. Right now, 
even knowing whether a particular script or build step is covered by tests is 
not straightforward.

At the same time, I think that the tiny subset of tests that webkit-patch used 
to run wasn't meaningful. Specifically, those were bindings tests and JSC API 
tests. These make even less sense in the EWS context, as the results were 
ignored if I remember correctly.

- Alexey


> 1 нояб. 2017 г., в 11:01, Aakash Jain  написал(а):
> 
> Hi Everyone,
> 
> Inside webkitpy, in tool/steps/runtests.py there is code to run various kind 
> of tests (JSC, bindings, webkitpy, webkitperl, layout-tests) which seems like 
> dead code. This code is not used by EWS (since ews pass --non-interactive 
> argument to webkit-patch). 
> 
> I believe the original intention of this code was to have a single command to 
> execute all our test-suites. Is there anyone who uses this functionality, by 
> manually running webkit-patch command with "--build-and-test --test" 
> arguments with an intention of running all possible test-suites?
> 
> If not, I am considering to remove this dead code to clean-up webkitpy.
> 
> References: https://bugs.webkit.org/show_bug.cgi?id=178608 
> , 
> https://bugs.webkit.org/show_bug.cgi?id=178599 
> 
> 
> Thanks
> Aakash
> ___
> 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] Formatting style for inline comments in Python code

2017-10-26 Thread Alexey Proskuryakov


> 26 окт. 2017 г., в 9:50, Brian Burg  написал(а):
> 
> why differ from the vast majority of all other Python code in existence, just 
> to be different? What's the point?


My point is that people familiar with all other Python code in existence will 
not be hacking on webkitpy. It's WebKit C++ developers who we want to 
contribute to webkitpy more, and super arbitrary differences that are 
impossible to rationalize are an unnecessary barrier to entry.

> If "WebKit developers" want to write Python code, perhaps they should learn 
> the Pythonic idioms of the language

I don't know if many people have the muscle memory to type a different number 
of spaces before a comment. I think that in practice, it's just about more 
iterations before EWS style checker is happy. What are we gaining by this?

- Alexey

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


Re: [webkit-dev] Formatting style for inline comments in Python code

2017-10-26 Thread Alexey Proskuryakov


> 25 окт. 2017 г., в 18:21, Michael Catanzaro  
> написал(а):
> 
> On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain  wrote:
>> Does anyone else has any opinion/preference for this?
> 
> The number of spaces before a comment really does not matter, but my $0.02: 
> PEP8 is an extremely common style for Python programs that all Python 
> developers are familiar with. I would follow that, and forget about trying to 
> adapt WebKit C++ style to an unrelated language. Trying to adapt the style 
> checker to ignore particular PEP8 rules seems like wasted effort.


There is definitely a number of PEP8 rules that we want to follow. But I don't 
think that there is anything about the two space before comment rule that makes 
it particularly fitting for Python.

I think that we should target WebKit developers with the coding style as much 
as possible, not Python developers. As we all agree on the one space rule 
elsewhere, why make a part of the code base uncomfortably different for most 
WebKit developers?

- Alexey

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


Re: [webkit-dev] SVN server broken?

2017-09-08 Thread Alexey Proskuryakov

Is anyone still seeing issues? I see a number of patches landed overnight, 
including by commit queue.

One problem I do see is that trac is stale.

- Alexey


> 8 сент. 2017 г., в 3:19, Carlos Alberto Lopez Perez  
> написал(а):
> 
> On 08/09/17 11:56, Carlos Alberto Lopez Perez wrote:
>> On 08/09/17 04:07, Ling Ho wrote:
>>> We have completed server maintenance works. Please email
>>> ad...@webkit.org if you encounter any problem.
>> 
>> It seems there is an issue with the SVN server?
>> Is rejecting both commits from commit-queue or manually landed.
>> 
>> $ git svn dcommit
>> Committing to http://svn.webkit.org/repository/webkit/trunk ...
>>  D   
>> Tools/wpe/patches/freetype6-2.4.11-truetype-font-height-fix.patch
>>  M   Source/WebCore/ChangeLog
>> 
>> ERROR from SVN:
>> Item is out of date: File '/trunk/Source/WebCore/ChangeLog' is out of date
>> W: 7e9ab8012eb85cca13a55ea65bc0f194c37a11b7 and refs/remotes/origin/master 
>> differ, using rebase:
>> :04 04 a0c128f45219a4f568ffb7b27336ca501b1fc64f 
>> 5f584218e40d75a9c39c52b76fd648459857f264 M   Source
>> :04 04 42e7bcb4148039d4fcc172c267b7db51f0ee98f8 
>> 7faa3cb8917a0bdbd9d0d34942b8d5422ee72eb9 M   Tools
>> Current branch master is up to date.
>> ERROR: Not all changes have been committed into SVN, however the committed
>> ones (if any) seem to be successfully integrated into the working tree.
>> Please see the above messages for details.
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> Also SVN trunk is still at r221777, but on the IRC channel #webkit WKR
> has claimed to have landed r221778 and r221779 (and closed bugs 176252
> and 176303), and I can't see this commits anywhere on the SVN.
> 
> ___
> 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] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-30 Thread Alexey Proskuryakov


> 30 авг. 2017 г., в 11:55, Andy Estes  написал(а):
> 
 In a completely other direction, what does this mean for use of Xcode? Can 
 we still build from Xcode? Debug?
>>> 
>>> CMake can generate Xcode files, so you can still develop and debug in Xcode.
>> 
>> This annihilates speed up possibility, as xcodebuild will be used instead of 
>> ninja
> 
> I don’t think so. I believe the generated Xcode project uses CMake when 
> building.


Per Keith's original e-mail, the plan is to add native support for unified 
build in WebKit Xcode projects, not relying on CMake in any way.

I have a separate question about the unified build plan though. Are we clear on 
how it will work with using declarations and directives in the global scope of 
.cpp and .mm files? We use these a lot, all over the place.

- Alexey


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


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov

> 12 мая 2017 г., в 16:12, Sam Weinig <wei...@apple.com> написал(а):
> 
> 
> 
>> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov <a...@webkit.org 
>> <mailto:a...@webkit.org>> wrote:
>> 
>> 
>>> 12 мая 2017 г., в 14:38, Sam Weinig <wei...@apple.com 
>>> <mailto:wei...@apple.com>> написал(а):
>>> 
>>> I regret piling on here, as I think this thread has diverged from it’s 
>>> original purpose, but…I understand this frustration. That said, perhaps 
>>> this is something we can solve with some tooling. For instance, a 
>>> run-test-in-safari (as a parallel to run-safari) script could be made which 
>>> starts the server, and then loads the test with the right URL in your built 
>>> Safari (or MiniBrowser, or whatever).  
>> 
>> 
>> That's still not good enough, as this means that I can't point someone else 
>> to an instance of the test on trac.webkit.org <http://trac.webkit.org/> to 
>> reproduce an issue. There is of course be another place to point to when/if 
>> the test gets upstreamed, but even that doesn't support stable links like 
>> trac does.
>> 
>> That's not to mention that learning the name of this proposed script is no 
>> easier than learning about run-webkit-httpd.
>> 
>> - Alexey
>> 
> 
> 
> I’m not sure what you mean by “good enough”.  Good enough for what?  What are 
> we debating here?

I think that I explained it very clearly, but let me try again.

When there is a test failure that I need to communicate to others, I say 
something "please open 
<https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/destroyed-image-load-event.html
 
<https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/border.html>>
 in Safari to reproduce". That's very easy to do, and makes it very easy for 
others to work on the issue.

If your test requires complex setup, like WPT does, then I may not have the 
time to write up complicated steps to reproduce, or the person who gets the bug 
may not have the time to follow them. Those people don't have a WebKit 
checkout, so scripts won't help. This makes the test less effective, as 
problems that it finds are less likely to be addressed.

- Alexey

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


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov

> 12 мая 2017 г., в 14:39, Ryosuke Niwa  написал(а):
> 
> This is absolutely not how I operate at all. Since almost all custom
> elements and shadow DOM API tests I wrote are written using
> testharness.js and upstreamed to web-platform-tests, they have been
> deleted from LayoutTests/fast/shadow-dom &
> LayoutTests/fast/custom-elements.
> 
> As such, if any new shadow DOM or custom elements tests under
> LayoutTests/imported/ start to fail, then we must fix them since we
> idon'thave any other test coverage.


I'll try to remember that. I do think that this means that shadow DOM and 
custom elements now have less effective tests, which may result in overlooking 
important issues.

- Alexey

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


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov

> 12 мая 2017 г., в 14:38, Sam Weinig  написал(а):
> 
> I regret piling on here, as I think this thread has diverged from it’s 
> original purpose, but…I understand this frustration. That said, perhaps this 
> is something we can solve with some tooling. For instance, a 
> run-test-in-safari (as a parallel to run-safari) script could be made which 
> starts the server, and then loads the test with the right URL in your built 
> Safari (or MiniBrowser, or whatever). 


That's still not good enough, as this means that I can't point someone else to 
an instance of the test on trac.webkit.org to reproduce an issue. There is of 
course be another place to point to when/if the test gets upstreamed, but even 
that doesn't support stable links like trac does.

That's not to mention that learning the name of this proposed script is no 
easier than learning about run-webkit-httpd.

- Alexey

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


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov

> 12 мая 2017 г., в 11:52, Ben Kelly <b...@wanderview.com> написал(а):
> 
> On Fri, May 12, 2017 at 2:26 PM, Rick Byers <rby...@chromium.org 
> <mailto:rby...@chromium.org>> wrote:
> On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov <a...@webkit.org 
> <mailto:a...@webkit.org>> wrote:
> Since imported WPT tests are very flaky, and are not necessarily written to 
> defend against important regressions, investigating issues with them is 
> relatively lower priority than investigating issues observed with WebKit 
> tests. So I would recommend not mixing tests for WebKit regressions with WPT 
> tests - if your test eventually ends up in LayoutTests/imported, it will 
> become a lot less effective.
> 
> FWIW this is absolutely NOT how we're treating this in chromium.  If this is 
> how things end up in practice then we will have failed massively in this 
> effort.
> 
> We figure if we want the web to behave consistently, we really have no choice 
> but to treat web-platform-tests as first class with all the discipline we 
> give to our own tests.  As such we are actively moving 
> <https://codereview.chromium.org/2877673004> many of our LayoutTests to 
> web-platform-tests and depending entirely on the regression prevention they 
> provide us from there.  Obviously there will be hiccups, but because our 
> product quality will depend on web-platform-tests being an effective and 
> non-flaky testsuite (and because we're starting to require most new features 
> have web-platform-tests before they ship), I'm confident that we've got the 
> incentives in place to lead to constant ratcheting up the engineering 
> discipline and quality of the test suite.
> 
> FWIW, mozilla also treats WPT as first class tests.  We're not actively 
> moving old tests to WPT like google, but all new tests (at least in DOM) are 
> being written in WPT.  Of course, we do have exceptions for some tests that 
> require gecko-specific features (forcing GC, etc).


We don't have a concept of "first class", but I hope that when choosing between 
looking into a simple test that was added for a known important bug, and 
looking into an imported test whose importance is unclear, any WebKit engineer 
will pick the former. And since no one can fix all the things, such 
prioritization makes imported tests less effective.

- Alexey

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


Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Alexey Proskuryakov

> 9 мая 2017 г., в 11:27, Simon Fraser  написал(а):
> 
> Another consideration here is "would my test be useful for other browser 
> vendors". I don't think the answer is a unanimous "yes", so I think we should 
> only use WPT for tests that will think are worth sharing.

Since imported WPT tests are very flaky, and are not necessarily written to 
defend against important regressions, investigating issues with them is 
relatively lower priority than investigating issues observed with WebKit tests. 
So I would recommend not mixing tests for WebKit regressions with WPT tests - 
if your test eventually ends up in LayoutTests/imported, it will become a lot 
less effective.

Using the complicated harness has a similar consequence - if you use any WPT 
goodies like templates or server side scripts, the cost of investigating issues 
on the test increases, and makes the test less valuable.

I don't know if there is any way to adopt WPT that won't make testing less 
effective. WPT tests may be useful in very rare cases, where we actively want 
to communicate certain subtle behavior details to other vendors - but even so, 
I imagine that other vendors may not put high priority on those, for the same 
reasons.

- Alexey

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


Re: [webkit-dev] Commits in branches triggering build in the bots now

2017-05-04 Thread Alexey Proskuryakov
Hi Carlos,

Could you please file a bug, and include the relevant links to investigate the 
issue?

- Alexey


> 4 мая 2017 г., в 0:46, Carlos Garcia Campos  написал(а):
> 
> I don't know what have changed, but now, commits in other branches are
> triggering builds in the bots. I have just realized after merging a
> couple of commits in GTK+ stable branch. This didn't happen before,
> those commits didn't show in the bots at all. 
> 
> Any idea why is this happening now? I don't see any relevant change in
> the buildbot config. For now I'll stop merging commits because I don't
> want the bots to waste the time building and running tests when nothing
> has actually changed.
> 
> Thanks, 
> Carlos Garcia Campos
> ___
> 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


[webkit-dev] Aakash Jain is now a WebKit Reviewer

2017-04-02 Thread Alexey Proskuryakov
Hi everyone,

I would like to announce that Aakash Jain is now a WebKit reviewer. Aakash 
works on WebKit tools and infrastructure. Please join me in congratulating 
Aakash, and send him some patches to review!

- Alexey

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


Re: [webkit-dev] Unable to log in to bugs.webkit.org

2017-04-01 Thread Alexey Proskuryakov
Done.

If anyone else hits this, please e-mail ad...@webkit.org 
. Resetting the password did work for other people, so 
clearly there is some flakiness to diagnose.

- Alexey

> 1 апр. 2017 г., в 10:24, Dan Bernstein  написал(а):
> 
> Can someone help me log in to by bugs.webkit.org  
> account?
> 
> I logged out of bugs.webkit.org  and now when I try 
> to log in with my email m...@webkit.org , an error 
> message appears saying that I must request a new password. When I click the 
> “request a new password” link, I receive two email messages in rapid 
> succession. The first one includes a password change link. The second one 
> says that the password change  has been canceled because I requested 
> cancellation. After that, the link from the first email is useless.
> ___
> 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


[webkit-dev] Bugzilla 5.0.3 password strength requirements

2017-03-21 Thread Alexey Proskuryakov
Hi,

Our updated Bugzilla installation now has password strength check enabled. It 
will refuse logging in with a weak password.

One specific tool that is affected is webkit-patch, which logs in every time. 
If it's giving you strange errors like the below, please try logging out from 
Bugzilla using browser UI, and logging back in again. If the password is 
considered weak, it will tell how to reset it.

Traceback (most recent call last):
  File "/OpenSource/Tools/Scripts/webkit-patch", line 84, in 
main()
  File "/OpenSource/Tools/Scripts/webkit-patch", line 79, in main
WebKitPatch(os.path.abspath(__file__)).main()
  File "/OpenSource/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 305, in main
result = command.check_arguments_and_execute(options, args, self)
  File "/OpenSource/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 123, in check_arguments_and_execute
return self.execute(options, args, tool) or 0
  File 
"/OpenSource/Tools/Scripts/webkitpy/tool/commands/abstractsequencedcommand.py",
 line 55, in execute
self._sequence.run_and_handle_errors(tool, options, state)
  File 
"/OpenSource/Tools/Scripts/webkitpy/tool/commands/stepsequence.py", line 
73, in run_and_handle_errors
self._run(tool, options, state)
  File 
"/OpenSource/Tools/Scripts/webkitpy/tool/commands/stepsequence.py", line 
67, in _run
step(tool, options).run(state)
  File "/OpenSource/Tools/Scripts/webkitpy/tool/steps/postdiff.py", line 
50, in run
self._tool.bugs.add_patch_to_bug(bug_id, diff, description, 
comment_text=comment_text, mark_for_review=self._options.review, 
mark_for_commit_queue=self._options.request_commit)
  File 
"/OpenSource/Tools/Scripts/webkitpy/common/net/bugzilla/bugzilla.py", 
line 633, in add_patch_to_bug
self.browser.select_form(name="entryform")
  File 
"/OpenSource/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_mechanize.py",
 line 524, in select_form
raise FormNotFoundError("no form matching "+description)
webkitpy.thirdparty.autoinstalled.mechanize._mechanize.FormNotFoundError: no 
form matching name 'entryform'


- Alexey



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


[webkit-dev] DEFERRED: Scheduled Outage: WebKit Bugzilla (bugs.webkit.org) March 13th, 2017 from 9AM PDT to Noon PDT

2017-03-11 Thread Alexey Proskuryakov
Hi,

The upgrade was deferred to a later date.

There will be svn.webkit.org  maintenance with some 
downtime on Monday afternoon. The exact time will be announced on Monday.

- Alexey

> 8 марта 2017 г., в 11:49, Ling Ho  > написал(а):
> 
> Hi,
> 
> We have scheduled an outage for upgrading Bugzilla (bugs.webkit.org 
> ) to version 5.0.3 on Monday, March 13th, 2017 from 
> 9AM PDT to Noon PDT. Please be informed and plan accordingly.
> 
> Please let me know if you have any questions or concerns.
> 
> Thanks,
> ...
> ling
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

- Alexey

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


Re: [webkit-dev] Can I get the editbugs-bit?

2017-03-01 Thread Alexey Proskuryakov

Done.

- Alexey

> 1 марта 2017 г., в 17:15, Suzuki, Basuke  
> написал(а):
> 
> Hi
>  
> My name is Basuke Suzuki, working at SONY Interactive Entertainment, a.k.a 
> PlayStation,
> working with Don Olmstead and Hironori Fujii
>  
> I want to ask to assign the editbugs-bit on me.
>  
> I have started to commit WebKit repository since last month. I filed some 
> bugs and
> also some of my fixes have already landed.
>  
> Bug 168486 – [WinCairo][MiniBrowser] Add ca-bundle to display secure pages 
> 
> Bug 134340 – curl: Improve errors by including the domain 
> 
> Bug 168843 – Windows build doesn’t start build if the git branch is not 
> master 
> Bug 168345 – [CURL] ResourceError created with error information should have 
> default type Type::General 
>  
> Regards,
>  
> Basuke Suzuki
>  
> ___
> 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] SVN trouble

2017-02-26 Thread Alexey Proskuryakov

Fixed bugmail, thank you for pointing it out. No e-mails should be lost, they 
were queued for delivery.

- Alexey

> 26 февр. 2017 г., в 11:36, Chris Dumez <cdu...@apple.com> написал(а):
> 
> It also seems bugzilla mail notifications may be down.
> 
> Chris Dumez
> 
> On Feb 25, 2017, at 8:40 AM, Simon Fraser <simon.fra...@apple.com 
> <mailto:simon.fra...@apple.com>> wrote:
> 
>> EWS is still down. Do we have an ETA?
>> 
>> Simon
>> 
>>> On Feb 24, 2017, at 10:25 PM, Alexey Proskuryakov <a...@webkit.org 
>>> <mailto:a...@webkit.org>> wrote:
>>> 
>>> 
>>>> 24 февр. 2017 г., в 19:50, Chris Dumez <cdu...@apple.com 
>>>> <mailto:cdu...@apple.com>> написал(а):
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov <a...@webkit.org 
>>>>> <mailto:a...@webkit.org>> wrote:
>>>>> 
>>>>> I believe that all infrastructure has recovered. We are currently looking 
>>>>> into one unrelated issue with webkit-queues, so EWS and commit queue 
>>>>> don't work.
>>>>> 
>>>>> - Alexey
>>>> 
>>>> 
>>>> It looks like EWS is still down. Did it break again or is it just not 
>>>> fixed yet?
>>> 
>>> 
>>> It did work for a period of time, but no conclusive fix yet.
>>> 
>>> - Alexey
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <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] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

> 24 февр. 2017 г., в 19:50, Chris Dumez <cdu...@apple.com> написал(а):
> 
> 
> 
> 
>> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov <a...@webkit.org 
>> <mailto:a...@webkit.org>> wrote:
>> 
>> I believe that all infrastructure has recovered. We are currently looking 
>> into one unrelated issue with webkit-queues, so EWS and commit queue don't 
>> work.
>> 
>> - Alexey
> 
> 
> It looks like EWS is still down. Did it break again or is it just not fixed 
> yet?


It did work for a period of time, but no conclusive fix yet.

- Alexey

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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

From my testing, bot git.webkit.org and git-svn work now.

The only thing I did was block access to 
cache/disk-cache/resources/shattered-2.pdf using authz (this is the file with 
collision). I think that the reason why mirrors only updated now is that 
someone committed to trunk, and thus invoked post-commit hooks.

I believe that all infrastructure has recovered. We are currently looking into 
one unrelated issue with webkit-queues, so EWS and commit queue don't work.

- Alexey


> 24 февр. 2017 г., в 11:29, Carlos Alberto Lopez Perez <clo...@igalia.com> 
> написал(а):
> 
> On 24/02/17 20:16, Alexey Proskuryakov wrote:
>> 
>> How does one create a local git-svn checkout to try this out? Given that
>> the offending file has been effectively deleted from svn, I think that
>> git-svn should work too.
> 
> You have the script:
> Tools/Scripts/webkit-patch setup-git-clone
> 
> And there is more doc here:
> https://trac.webkit.org/wiki/UsingGitWithWebKit
> 
> I can confirm that now it seems to work :) Thanks.
> 
> Also the git mirror is now updated beyond r212951.
> 
> How do you fixed this?
> 
> I see now that the files on r212951 have different sha1 hashes:
> 
> $ svn co 
> https://svn.webkit.org/repository/webkit/trunk/LayoutTests/http/tests/cache/@r212951
> 
> $ find cache/|grep pdf|xargs sha1sum
> 1880d3e60a5f888c5eb077dd6c52a9a80423d971  
> cache/disk-cache/resources/shattered-1-nocollision.pdf
> 38762cf7f55934b34d179ae6a4c80cadccbb7f0a  
> cache/disk-cache/resources/shattered-1.pdf
> 682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  
> cache/disk-cache/resources/shattered-2-nocollision.pdf
> 
> 
> ___
> 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] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

> 24 февр. 2017 г., в 9:31, Carlos Alberto Lopez Perez <clo...@igalia.com> 
> написал(а):
> 
> On 24/02/17 18:08, Alexey Proskuryakov wrote:
>> works. There is almost certainly more cleanup that needs to be done - I
>> can see that trac.webkit.org <http://trac.webkit.org> is broken. Please

Trac works now.

> git-svn is broken


How does one create a local git-svn checkout to try this out? Given that the 
offending file has been effectively deleted from svn, I think that git-svn 
should work too.

- Alexey


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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

> 24 февр. 2017 г., в 7:48, Antti Koivisto  написал(а):
> 
> Hi,
> 
> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 
>  caused some sort of SVN 
> problem. Please hold commits until this is resolved.

I deleted the remaining PDF file from resources, so svn checkout now works. 
There is almost certainly more cleanup that needs to be done - I can see that 
trac.webkit.org  is broken. Please reply to the thread 
about what else you see not working.

- Alexey



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


Re: [webkit-dev] Upstreaming Tests from WebKit to Web Platform Tests

2017-02-06 Thread Alexey Proskuryakov

> 6 февр. 2017 г., в 12:28, Ryosuke Niwa  написал(а):
> 
> The concern I've heard about is not how run-webkit-tests run the tests. It's 
> about how a test is opened inside a browser, DRT, WTR while debugging.

+1

I think that making web platform tests more practical for engineers to work 
with should be a pre-requisite for deeper integration.

From tools perspective, cleaning up the way we get supporting scripts for web 
platform tests would be quite beneficial too. It is very hard to reason about 
what happens in a merge that just updates .tar.gz files or a SHA hash.

- Alexey


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


Re: [webkit-dev] [webkit-reviewers] usage of auto

2017-01-11 Thread Alexey Proskuryakov

There are two considerations which make me skeptical that auto is a good thing.

1. There are many smart pointer types in C++, and ignoring pointer types is 
very error prone. Others have mentioned std::optional, and mistakes being made 
with RefPtrs. I even saw a case where a review comment that suggested switching 
to auto, but it would have introduced memory corruption if followed.

Some specific cases of this may become irrelevant as PassRefPtr goes away, but 
I don't think that there is any expectation that smart pointers in general are 
going away.

2. I also find that types in code are an important part of documenting how it 
is supposed to work. In a way, these are read-time assertions. An assertion can 
be wrong and they are compiled out in release builds, yet they prove to be 
highly valuable anyway. Similarly, a type can be wrong, but it tells me as the 
reader what the author thinks their code is doing, and lets me focus on other 
parts of it for the first pass at least.

A very similar kind of type agnostic coding has always been used in templates, 
and it feels like a well established belief that it takes engineers with high 
levels of expertise to write generic code in templates. And if it's harder, I 
don't see why using these techniques all over the place is beneficial.

- Alexey


> 11 янв. 2017 г., в 9:15, Darin Adler  написал(а):
> 
> OK, you didn’t convince me but I can see that your opinions here are strongly 
> held!
> 
> — Darin
> ___
> 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] Asserting versus throwing in internals and testRunner objects

2016-09-23 Thread Alexey Proskuryakov

Note that we are talking about API misuse here, so associating the crash with a 
test is not really needed - it's the test that you are writing.

I've seen tests getting checked in even when they don't run to completion and 
raise JS exceptions. I want it to be very clear and obvious when a test is bad, 
and a console log is too subtle of a clue. Additionally, I don't really see 
much difference between these asserts that we use in TestRunner and asserts in 
shipping code. Both are about unexpected conditions, so if we want to avoid 
crashing, shouldn't we also convert all ASSERTs into log messages?

Ultimately, I don't think that it is fair to think about testRunner and tests 
themselves as separate entities, which is of course the way we think about 
WebKit and web content. Tests are designed with testRunner limitations in mind, 
and if these limitations are not respected, the response should be the same as 
for any expectation mismatch between C++ functions. Making the connection 
weaker will make it harder to maintain the tests.

- Alexey


> 23 сент. 2016 г., в 16:26, Geoffrey Garen  написал(а):
> 
> I vote for throwing a JS exception.
> 
> In my experience, tests that crash are harder to deal with than tests that 
> throw JS exceptions. A backtrace is a less informative than the message “you 
> called internals.X without a frame”. Symbolication takes a long time. And 
> sometimes we have trouble associating crash logs with specific tests.
> 
> Geoff
> 
>> On Sep 23, 2016, at 2:25 PM, Ryosuke Niwa  wrote:
>> 
>> Hi all,
>> 
>> In https://bugs.webkit.org/show_bug.cgi?id=161919, a question was
>> raised as to what would be the best practice when one of internals or
>> testRunner method is called at an undesirable timing or wrong
>> arguments.  The case in question was about calling it on a document
>> without a frame when the method required a frame.
>> 
>> What would be the desired outcome of making such a method call?
>> Should we be asserting it and crashing the process?  Or should we be
>> throwing an exception?
>> 
>> - R. Niwa
>> ___
>> 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


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


Re: [webkit-dev] "Fake" ref-tests

2016-07-22 Thread Alexey Proskuryakov

> 22 июля 2016 г., в 22:34, Darin Adler <da...@apple.com> написал(а):
> 
>> On Jul 22, 2016, at 10:25 PM, Alexey Proskuryakov <a...@webkit.org> wrote:
>> 
>> Simon and I were trying to move all tests out of platform/ directories.
> 
> Is this nearly done? Can we take that feature out of the test running script?

There are 236 .html files in LayoutTests/platform/ at this time, and a few 
tests of other types.

https://bugs.webkit.org/show_bug.cgi?id=147586 Move tests out of platform 
directories
https://bugs.webkit.org/show_bug.cgi?id=147587 check-webkit-style should warn 
about tests in platform directories

- Alexey

> Anyone have any objections to this?
> 
> — Darin


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


Re: [webkit-dev] "Fake" ref-tests

2016-07-22 Thread Alexey Proskuryakov

> 22 июля 2016 г., в 21:57, Darin Adler  написал(а):
> 
>> What is the right way to deal with tests like these?
> 
> I think we should move the tests into platform/mac.

Simon and I were trying to move all tests out of platform/ directories. When 
the expected results are different across OS versions, or between WebKit1 and 
WebKit2, it gets really confusing where to put the expected results.

As much as possible, platform specific tests should be in directories named 
after a specific technology that's skipped on platforms that don't have it. In 
this case where it's just platform specific, fast/borders/mac would work best I 
think.

- Alexey

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


Re: [webkit-dev] ./Tools/Scripts/run-safari doesn't work with Safari 10

2016-07-18 Thread Alexey Proskuryakov
Hello Marco,

> 18 июля 2016 г., в 13:02, Marco Barisione  
> написал(а):
> 
> Hello,
> 
> I recently installed Safari 10 on some machines running 10.11.6 DP. 
> Unfortunately, I cannot get Safari 10 to work with WebKit compiled from SVN.
> 
> I tried with both SVN trunk (from today) and the revision tagged in SVN that 
> corresponds to my currently installed Safari (602.1.38.4).
> I compiled Safari with the usual:
> 
>  $ ./Tools/Scripts/build-webkit
> 
> And then I tried to run Safari with:
> 
>  $ ./Tools/Scripts/run-safari
> 
> Safari 10 starts, but nothing loads probably because it cannot load its 
> injected bundle. This is the output:
> 
> Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to 
> built WebKit in /Users/bari/src/webkit/WebKitBuild/Release.
> 2016-07-18 14:18:32.900 SafariForWebKitDevelopment[424:4918] [Keychain] 
> SecItemCopyMatching failed fetching extension list with error -34018
> 2016-07-18 14:18:32.923 SafariForWebKitDevelopment[424:4918] [Keychain] 
> SecItemCopyMatching failed fetching extension list with error -34018
> 2016-07-18 14:18:33.091 com.apple.WebKit.WebContent.Development[425:4983] 
> Error loading 
> /System/Library/StagedFrameworks/Safari/Safari.framework/Safari:  
> dlopen(/System/Library/StagedFrameworks/Safari/Safari.framework/Safari, 265): 
> Symbol not found: _OBJC_CLASS_$_WBSCompletionListRankingObserver
>  Referenced from: 
> /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
>  Expected in: 
> /System/Library/PrivateFrameworks/SafariShared.framework/Versions/A/SafariShared
> in /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
> InjectedBundle::load failed - Could not load the executable from the bundle.

There are a couple things that look unexpected to me here. Since it's about 
Safari 10, could you please file a bug at https://bugreport.apple.com, 
attaching a sysdiagnose ("sudo sysdiagnose" in Terminal)?

Please feel free to e-mail me the bug number to take a look.

- Alexey



> 
> I’m a bit surprised that I couldn’t find anything about this problem in 
> bugzilla, IRC or on this mailing list.
> Am I doing something wrong or is this a problem with newer Safari? Is there 
> any fix/workaround for this?
> 
> Thank you!
> 
> -- 
> Marco Barisione
> 
> ___
> 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] How to deal with 1-pixel differences in reftests ?

2015-11-18 Thread Alexey Proskuryakov
Hi,

I do not think that there is a way to algorithmically define what an acceptable 
difference is. Here are a few cases where it's critical to detect small 
differences:

- color management, e.g. testing different code paths that should match 
precisely;
- finding uninitialized memory use bugs in rendering pipeline, which do cause 
minor pixel noise;
- testing antialiasing and scaling behavior (e.g. that we should revert to high 
quality scaling after an animation is done);
- testing text rendering, where the difference can easily be small, e.g one 
accent over one letter on a mostly blank test result.

Talking from past experience that we had with pixel test tolerance and with 
retrying failing tests, I believe that leeway in reporting failures quickly 
causes significant deterioration in infrastructure quality, up to a point where 
we can't tell what's going on with many tests.

- Alexey



> 18 нояб. 2015 г., в 4:36, Carlos Alberto Lopez Perez  
> написал(а):
> 
> Hi,
> 
> Some reference tests give a 1-pixel or very few pixel differences [1].
> 
> I'm not sure if this really indicates a problem in the WebKit code, or
> it indicates that we are just too strict not allowing even a very small
> percentage in pixel differences for this kind of tests.
> 
> Should we tolerate a few pixel differences for reftests ?
> 
> I have done some tests, and the test in [1] passes for any value of
> tolerance >= 0.1% (with the GTK port).
> 
> I'm inclined to allow a very small value, for example a 0.001% (that
> would be 100 times stricter than the tolerance value we use for the
> other tests)
> 
> 
> Regards
> ---
> 
> [1]
> 
> For example, this is happening in the GTK port:
> https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r192415%20%2812243%29/imported/blink/fast/canvas/canvas-clip-stack-persistence-diffs.html
> The diff image normalized (so you can see where is the diff):
> http://people.igalia.com/clopez/wkbug/151261/canvas-clip-stack-persistence-diff_normalized.png
> 
> 
> ___
> 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] How to deal with 1-pixel differences in reftests ?

2015-11-18 Thread Alexey Proskuryakov

> 18 нояб. 2015 г., в 11:50, Simon Fraser  написал(а):
> 
> There are some well-understood reasons why a test might not exactly match its 
> reference. One is that the test uses compositing layers to do clipping, but 
> the reference just clips with drawing, and these are not expected to give a 
> pixel-perfect match.
> 
> I proposed a way to allow a test to specify a custom tolerance in 
> https://bugs.webkit.org/show_bug.cgi?id=149828 
> . If we had this, it would 
> allow me to fix 142258  and 
> 146523 .

Bug 142258 also serves as an example for why we shouldn't do this. Both known 
reasons for it are actual bugs that needed to be discovered, and need to be 
fixed.

What are the causes for flakiness in bug 146523?

- Alexey

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


Re: [webkit-dev]

2015-11-17 Thread Alexey Proskuryakov
Hello Yoav,

Is there any technology on the horizon that would simplify doing this kind of 
optimization? If done manually, this seems:
- complicated, so only a few sites will do this;
- very likely to go stale, as the content changes, but preload instructions do 
not get updated;
- related to the above, the failure mode is opaque, as the website will only 
get a little slower to load, and not break functionally.

Sending the preload requests in HTTP response headers seems like it would 
provide the most benefit, but is also more prone to the above issues.

Preloading resources as untyped data doesn't seem like a good match to the 
loader implementation mostly dealing with typed resources. Additionally, 
fetching depends on the referring document's properties (notably the charset is 
inherited for same origin subresources). This is not necessarily a blocker, but 
the proposal adds a different way to think about subresource loading.

There appears to be some feature duplication with HTTP/2 server push 
functionality, could you please characterize the differences that would make it 
worth having both?

- Alexey


> 11 нояб. 2015 г., в 6:11, Yoav Weiss  написал(а):
> 
> Hi,
> 
> I'm interested in adding support for  
>  and the corresponding "Link:" headers and 
> wanted to gauge interest for supporting the feature.
> 
> The preload relationship provides a declarative fetch primitive that enables 
> developers to initiate a resource fetch and separate fetching from resource 
> execution. As such, preload is a low-level primitive that enables 
> applications to build custom resource loading and execution behaviors without 
> hiding resources from the user agent and incurring delayed resource fetching 
> penalties. 
> 
> Use cases include:
> * Early fetch of lately discovered critical resources - Sites that contain 
> critical resources that aren't discoverable by the preload scanner (e.g. 
> fonts, JS loaded scripts and styles, etc) can use the feature to download 
> these critical resources early
> * Separation of download and execution in a declarative, non-hacky way.
> 
> All in all, it would enable Web sites to significantly improve loading 
> performance in various common scenarios.
> 
> Thanks!
> Yoav
> 
> ___
> 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] Windows EWS not working?

2015-11-07 Thread Alexey Proskuryakov
(re-sending from the right e-mail address for the list)

> 7 нояб. 2015 г., в 16:56, Darin Adler  написал(а):
> 
> I was looking at the patch in this bug:
> 
> https://bugs.webkit.org/show_bug.cgi?id=150967
> 
> The patch was posted 20 hours ago. EWS has processed this for all platforms 
> other than Windows, but it says “win #61”, so it seems like the Windows bot 
> has 60 other patches to process before getting to this one.
> 
> Does this mean the Windows EWS is stuck? Who can get it unstuck?

Yes, Windows EWS bots fail to start with the below error. I think that this is 
a regression from , so Daniel Bates 
has volunteered to look into this.

Starting Queue
Traceback (most recent call last):
 File "/home/buildbot/WebKit/Tools/Scripts/webkit-patch", line 84, in 
   main()
 File "/home/buildbot/WebKit/Tools/Scripts/webkit-patch", line 79, in main
   WebKitPatch(os.path.abspath(__file__)).main()
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 305, in main
   result = command.check_arguments_and_execute(options, args, self)
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/multicommandtool.py", 
line 123, in check_arguments_and_execute
   return self.execute(options, args, tool) or 0
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/commands/queues.py", 
line 153, in execute
   return engine(self.name, self, self._tool.wakeup_event, 
self._options.seconds_to_sleep).run()
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/bot/queueengine.py", 
line 91, in run
   self._delegate.begin_work_queue()
 File 
"/home/buildbot/WebKit/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py",
 line 56, in begin_work_queue
   self._layout_test_results_reader = LayoutTestResultsReader(self._tool, 
self._port.results_directory(), self._log_directory())
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/port/base.py", line 777, in 
results_directory
   option_val = self.get_option('results_directory') or 
self.default_results_directory()
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/port/base.py", line 791, in 
default_results_directory
   return self._build_path('layout-test-results')
 File "/home/buildbot/WebKit/Tools/Scripts/webkitpy/port/win.py", line 134, 
in_build_path
   root_directory = self._filesystem.join(self.get_option('root'), 
binary_directory)
 File 
"/home/buildbot/WebKit/Tools/Scripts/webkitpy/common/system/filesystem.py", 
line 151, in join
   return os.path.join(*comps)
 File "/usr/lib/python2.7/posixpath.py", line 77, in join
   elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'

- Alexey

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


Re: [webkit-dev] Mac EWS Updates!

2015-10-21 Thread Alexey Proskuryakov

Normally, we try to configure EWS with OS versions that most engineers no 
longer use on their machines, to maximize the chances of catching problems that 
one can't catch locally.

It would certainly be ideal to cover the full spectrum, as many contributors 
don't have Macs at all.

- Alexey

> 20 окт. 2015 г., в 22:54, Ryosuke Niwa  написал(а):
> 
> Great!  Are you also planning to replace those Mavericks EWS bots with
> El Capital bots?
> - R. Niwa
> 
> 
> On Wed, Oct 21, 2015 at 7:24 AM, Lucas Forschler  wrote:
>> Hello everyone!
>> 
>> Apple has added two new EWS queues to our infrastructure.
>> Alongside our iOS, mac, and mac-wk2 queues, you will now see the following
>> two additions: mac-debug & mac-32bit
>> 
>> This puts our current EWS configuration as follows:
>> 
>> iOS:
>> ARMv7 Release (build only)
>> mac:
>> Mavericks 64-bit WK1 Release (build and test)
>> mac-wk2:
>> Mavericks 64-bit WK2 Release (build and test)
>> mac-debug:
>> Yosemite 64-bit Debug (build and test)
>> mac-32bit:
>> Yosemite 32-bit Release (build only)
>> 
>> Please watch your patches for results on the new queues!
>> 
>> Thanks,
>> Lucas
>> 
>> ___
>> 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

- Alexey

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


Re: [webkit-dev] Bugzilla default assignees

2015-09-14 Thread Alexey Proskuryakov

Yet another approach used by the Accessibility component is to have a technical 
account auto-CC'ed, and then anyone interested can follow this account. This 
seems like the most reliable solution to me.

- Alexey



14 сент. 2015 г., в 9:26, Brian Burg  написал(а):

> It should be possible for an administrator to set a component's default 
> assignee and default cc: list. We use the default-cc approach for the Web 
> Inspector component (though it often goes out of date).
> 
> However, the default assignee approach seems nice from a self-service POV, 
> and we don’t seem to rely on the assignee field too much in the WebKit 
> bugzilla. What do others think?
> 
> Brian
> 
>> On Sep 12, 2015, at 4:48 PM, Michael Catanzaro  wrote:
>> 
>> Hi,
>> 
>> In WebKit Bugzilla the default assignee for all bugs is Nobody. This is
>> problematic because it makes it really hard to notice when new bugs are
>> filed against a particular component. For example, I want to be CCed on
>> all new bugs in the WebKit Gtk component. If there was a fake default
>> assignee, say webkit-gtk-ma...@webkit.bugs, then I could just add that
>> email to the User Watching section under my Email Preferences, and I'd
>> notice whenever a bug in that component is filed or changes state. This
>> is what we do in GNOME Bugzilla and it works quite well.
>> 
>> Since we don't have that, what I've been doing is watching Carlos
>> Garcia, which is a decent approximation since he tends to get CCed on a
>> lot of bugs. :) But only regular contributors know to CC him, so if the
>> bug isn't filed by a regular contributor, nobody ever sees it.
>> 
>> If a Bugzilla admin could set up default assignees for the various
>> components (or at least the WebKit Gtk component, but it would be
>> useful for all of them), that would be awesome.
>> 
>> Thanks,
>> 
>> Michael
>> ___
>> 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

- Alexey


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


Re: [webkit-dev] Commit queue issues

2015-09-02 Thread Alexey Proskuryakov

02 сент. 2015 г., в 5:41, Philippe Normand  написал(а):

> It seems the commit queue cannot land patches?
> 
> https://bugs.webkit.org/show_bug.cgi?id=148702

This should be resolved now. I see that you already marked this patch for cq+ 
again; I'll see if any others are stuck.

- Alexey



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


Re: [webkit-dev] Commit queue issues

2015-09-02 Thread Alexey Proskuryakov

> 2 сент. 2015 г., в 9:59, Alexey Proskuryakov <a...@webkit.org> написал(а):
> 
> 
> 02 сент. 2015 г., в 5:41, Philippe Normand <ph...@igalia.com> написал(а):
> 
>> It seems the commit queue cannot land patches?
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=148702
> 
> This should be resolved now. I see that you already marked this patch for cq+ 
> again; I'll see if any others are stuck.

The issue re-occurred later in the day, and should be really resolved now. Many 
thanks to everyone who worked on fixing it!

- Alexey

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


Re: [webkit-dev] Switching servers for EWS and flakiness dashboard [Caution: Message contains Suspicious URL content]

2015-07-31 Thread Alexey Proskuryakov

I tried running the style queue from command line, and it processed some 
patches, errored out on some others, and then hit a different error. 

I restarted the queue normally then, and it has processed all patches except 
for https://bugs.webkit.org/attachment.cgi?id=257920action=prettypatch. We 
probably need to find a way to enable more logging to find the problem(s). 
Looks like the bot has trouble talking to bugzilla.

Running WebKit style-queue.
Starting Queue
Logging in as commit-qu...@webkit.org...
Fetching: https://bugs.webkit.org/attachment.cgi?id=257909action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147484ctype=xmlexcludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257909action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147484ctype=xmlexcludefield=attachmentdata
Error: style-queue did not process patch.
Releasing work item 257909 from style-queue
Unable to process work item.
Fetching: https://bugs.webkit.org/attachment.cgi?id=257916action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147486ctype=xmlexcludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257916action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147486ctype=xmlexcludefield=attachmentdata
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style clean
Cleaned working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style update
Updated working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-attachment --no-update --non-interactive 257916
Applied patch
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-watchlist-local 147486
Watchlist applied
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style check-style-local --non-interactive --quiet
Style checked
Pass
Releasing work item 257916 from style-queue
Fetching: https://bugs.webkit.org/attachment.cgi?id=257917action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147297ctype=xmlexcludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257917action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147297ctype=xmlexcludefield=attachmentdata
Error: style-queue did not process patch.
Releasing work item 257917 from style-queue
Unable to process work item.
Fetching: https://bugs.webkit.org/attachment.cgi?id=257832action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147107ctype=xmlexcludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257832action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147107ctype=xmlexcludefield=attachmentdata
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style clean
Cleaned working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style update
Updated working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-attachment --no-update --non-interactive 257832
Applied patch
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-watchlist-local 147107
Watchlist applied
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style check-style-local --non-interactive --quiet
Style checked
Pass
Releasing work item 257832 from style-queue
Fetching: https://bugs.webkit.org/attachment.cgi?id=257918action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147487ctype=xmlexcludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257918action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147487ctype=xmlexcludefield=attachmentdata
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style clean
Cleaned working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style update
Updated working directory
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-attachment --no-update --non-interactive 257918
Applied patch
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style apply-watchlist-local 147487
Watchlist applied
Running: webkit-patch --status-host=webkit-queues.webkit.org 
--bot-id=webkit-misc-style check-style-local --non-interactive --quiet
Style checked
Pass
Releasing work item 257918 from style-queue
Fetching: https://bugs.webkit.org/attachment.cgi?id=257919action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147488ctype=xmlexcludefield=attachmentdata
Fetching: https://bugs.webkit.org/attachment.cgi?id=257919action=edit
Fetching: 
https://bugs.webkit.org/show_bug.cgi?id=147488ctype=xmlexcludefield=attachmentdata
Error: style-queue did not process patch.
Releasing work item 257919 from style-queue

Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

2015-04-24 Thread Alexey Proskuryakov

24 апр. 2015 г., в 9:06, Brady Eidson beid...@apple.com написал(а):

 Killing the feature would lead to a confusing experience for such users.

Additionally, I think that outright killing multipart main resources would 
cause unnecessarily confusing experience for WebKit developers. One of the 
first things we do when a resource is not displayed correctly is open it in in 
a new window.

It definitely seems appropriate to limit what we claim to support, making the 
main resource code path more like the subresource one, and removing code 
complexity along the way.

Anyway, the evidence of someone on the WebKit team being affected by this as a 
user seems like a fairly strong argument in this case.

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


Re: [webkit-dev] Running W3C tests using wptserve

2015-02-01 Thread Alexey Proskuryakov

This issue occurs on Mac bots. Windows EWS does not run regression tests, so it 
would not be affected.

Here is the log output:

WARNING:web-platform-test-launcher:/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test/__init__.py
 is not present, creating it as empty file
Traceback (most recent call last):
  File 
/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/servers/web_platform_test_launcher.py,
 line 21, in module
create_wpt_empty_file_if_needed(['tools', 'pywebsocket', 'src', 'test', 
'__init__.py'])
  File 
/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/servers/web_platform_test_launcher.py,
 line 17, in create_wpt_empty_file_if_needed
open(file_path, 'a').close()
IOError: [Errno 2] No such file or directory: 
'/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test/__init__.py'

Looks like the directory 
/Volumes/Data/EWS/WebKit/LayoutTests/imported/w3c/web-platform-tests/tools/pywebsocket/src/test
 does not exist.

- Alexey

 1 февр. 2015 г., в 0:27, youenn fablet youe...@gmail.com написал(а):
 
 Looking at the log, the dependencies seem to be installed correctly.
 Is it possible to get access to the corresponding
 WebKitBuild/Release/layout-test-results, in particular
 wptwk_process_log.out.txt?
 
 Also, does it happen on all bots or only windows bot?
 
 
 2015-02-01 4:41 GMT+01:00 Alexey Proskuryakov a...@webkit.org:
 
 31 янв. 2015 г., в 11:57, youenn fablet youe...@gmail.com написал(а):
 
 Currently, only two tests are run within that folder:
 - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
 - web-platform-tests/domparsing/insert-adjacent.html
 
 Should there be any issus with those tests, the problem may be related
 to running wptserve.
 
 I see that these tests fail on EWS, any suggestions for how to debug the 
 issue? The EWS setup is not much different from regular bots - the biggest 
 difference is that EWS machines have more cores.
 
 https://webkit-queues.appspot.com/results/6309998137180160
 
 - Alexey
 


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


Re: [webkit-dev] Running W3C tests using wptserve

2015-01-31 Thread Alexey Proskuryakov

 31 янв. 2015 г., в 11:57, youenn fablet youe...@gmail.com написал(а):
 
 Currently, only two tests are run within that folder:
 - web-platform-tests/domparsing/DOMParser-parseFromString-html.html
 - web-platform-tests/domparsing/insert-adjacent.html
 
 Should there be any issus with those tests, the problem may be related
 to running wptserve.

I see that these tests fail on EWS, any suggestions for how to debug the issue? 
The EWS setup is not much different from regular bots - the biggest difference 
is that EWS machines have more cores.

https://webkit-queues.appspot.com/results/6309998137180160

- Alexey

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


Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

2015-01-23 Thread Alexey Proskuryakov

23 янв. 2015 г., в 10:01, Ryosuke Niwa rn...@webkit.org написал(а):

 We could add a new test expectation like ImageDiff to suppress these or we 
 could expose a new internals or testRunner methods to mark a test as such.

Good idea! An ImageHashMismatch expectation seems like a reasonable way to 
silence the noise.

Also, I am surprised that we weren't getting a specific message about size 
mismatch here, as Darin suggested. In fact, we used to have this very output on 
other tests until very recently (see 
https://bugs.webkit.org/show_bug.cgi?id=139884).

- Alexey

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


Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

2015-01-22 Thread Alexey Proskuryakov

22 янв. 2015 г., в 11:30, Simon Fraser simon.fra...@apple.com написал(а):

 This happens when the expected and actual images are very close, but not 
 identical. ImageDiff has some built-in rounding that effectively acts as a 
 small tolerance, so the hashes are different, but ImageDiff incorrectly says 
 the images are the same. For example, some of the tests in question render a 
 green box either via CALayers, or by painting, and there’s a slight color 
 difference between the two code paths.
 
 My preference for how to fix this would be to fix ImageDiff to remove its 
 slight built-in tolerance, and then to expose testRunner API to allow a test 
 to set an explicit tolerance. There are many cases where we’d like to use ref 
 tests, but are unable to because of slight, justifiable rendering 
 differences, and having an explicit tolerance would permit the use of ref 
 tests in these cases.

One thing about tolerance is that it is super confusing - are we talking about 
the number of pixels that are different, or about how different the pixels are? 
Also, a lot of failures only cause small differences in pixel results. Even a 
100x100 box that becomes red instead of green is only a small portion of the 
800x600 image, and it's even more the case for tests that check e.g. text 
rendering.

It is not currently known what the root causes are for the tests that say ref 
test hashes didn't match but diff passed. Given that the differences are very 
tiny, one guess is that even though compositing and non-compositing code paths 
are mathematically equivalent, there are different rendering steps taken, and 
rounding at each step adds up to slight differences. Another theory is that we 
have actual bugs, such as with color management.

If it's just rounding differences, then the right thing to do is probably to 
silence the console output, keeping behavior the same otherwise.

- Alexey

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


Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

2015-01-22 Thread Alexey Proskuryakov

 22 янв. 2015 г., в 17:57, Darin Adler da...@apple.com написал(а):
 
 What about the test I cited?
 
 svg/css/svg-resource-fragment-identifier-img-src.html

This particular test is buggy - it is a hidpi test, so it dumps results as a 
1600x1200 image, but its -expected.html is not hidpi, and is dumped as 800x600, 
so hashes are obviously different. I now filed 
https://bugs.webkit.org/show_bug.cgi?id=140815 about this test.

When we compare pixels, we draw both images into bitmaps of the same size, so 
they become similar enough for ImageDiff to consider them identical.

Earlier today, Simon and I agreed that we should just silence the error 
message, because it only tells us about minor color differences that are 
inevitable when comparing compositing vs. non-compositing. Looks like it tells 
us about more actionable issues, too. Also, I just found 
https://bugs.webkit.org/show_bug.cgi?id=69444, and I think that its rationale 
applies in this case, too.

So we should probably keep this error message. I'm not sure whether we should 
make it a hard error though.

- Alexey

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


Re: [webkit-dev] review times

2014-12-03 Thread Alexey Proskuryakov

03 дек. 2014 г., в 2:32, Daniel Lazarenko dani...@opera.com написал(а):

 Whatsoever it would be nice find a new reviewer for my patch. Does anybody 
 want to take it?

Just to be clear about this part, the reviewer should not be just anybody. 
This patch is part of an effort to implement a new feature in WebKit2 that at 
least some of us consider wrong, so the reviewer needs to have appropriate 
authority over WebKit2 feature set.

The reviewership system is working as designed here, this is not an easy patch 
to approve.

- Alexey

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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-30 Thread Alexey Proskuryakov

 24 нояб. 2014 г., в 1:28, Antti Koivisto koivi...@iki.fi написал(а):
 
 I don't think this is really 32bit vs 64bit platform issue. The vast majority 
 of 64bit systems our users have (that is iOS devices) can't use memory 
 buffers sized anywhere near the 32bit limit even in theory. Also when using 
 Vector auto-grow capabilities (which is really the point of using a vector 
 instead of just allocating a buffer) you need way more memory than the actual 
 data size. Growing a Vectoruint8_t beyond 4GB has peak allocation of 9GB.

The argument that we should support the same functionality across all devices 
is a pretty strong one. However it's not as simple as it may sound.

1. The user impact is different. I haven't seen any reports of people trying 
this on iOS devices, so the importance of fixing the problem on iOS is lower 
than the importance of fixing it on OS X, where people actually do encounter it 
in practice.

2. Relative cost of supporting large files on memory constrained devices may be 
different (e.g. using off_t as Maciej proposed might be too big of a 
performance hit). When we know it, we can decide whether the ability to upload 
large files is worth the cost.

3. The scope of work required to make this work is likely different. I suspect 
that uploading such huge files from iOS Safari is currently essentially 
impossible for other reasons (we can discuss it in more detail offline).

Also, the argument against huge Vectors is a straw man one. What I'm saying is 
we have a lot of code that already needs to deal with large sizes, and this 
code is everywhere. It's not like we have a large data world and a small data 
world inside WebKit, and can perform magnitude checks at the boundary. It's 
quite the opposite, everything works together, and the practical solution is to 
have checks isolated inside Vector.

 Are there any examples of Vectors in the current code base where we would 
 usefully fix an actual problem even in medium term by switching to 64bit 
 storage sizes? I don't think they exists. Cases like file uploads should 
 stream the data or use some mapped-file backed buffer type that is not a 
 Vector.

With modern APIs that are now exposed to JS code, file uploads are no longer an 
isolated code path. The Blob is sliced, partially read into memory and 
processed. It is almost certain that YouTube and Google Drive don't attempt to 
read huge slices, so 32-bit lengths in Vectors and even ArrayBuffers will 
probably work in practice. But it's not appropriate for all users of Vector to 
perform the checks, because failure to do them right will have serious 
consequences.

- Alexey

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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Alexey Proskuryakov

19 нояб. 2014 г., в 14:58, Alexey Proskuryakov a...@webkit.org написал(а):

 These and related uses are all over the place - see also Vectors in 
 FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, 
 plug-in code that loads from network, SharedBuffer etc.

Another way to say this is: we need to deal with large data arrays throughout 
loading code. We do not really need full size vectors in most other code - it's 
sort of OK for HTML parser or for image decoder to fail catastrophically when 
there is too much data fed to it.

This is somewhat questionable design, but if we are going to stick to it, then 
magnitude checks should be centralized, not sprinkled throughout the code. We 
should not make this check explicitly when feeding a network resource to the 
parser, for example.

A 64-bit API for Vector solves this nearly flawlessly. We do not perform the 
checks manually every time we use a Vector, Vector does them for us.

Other options are:

- uint64_t everywhere. This way, we'll solve practical problems with large 
resources once and for all. Also, this may prove to be necessary to solve even 
YouTube/Google Drive uploads, I do not know that yet.

- size_t everywhere. Same effect on 64-bit platforms, while 32-bit ones will 
still be limited. I like this option, because it won't make us pay the memory 
and performance cost on old crippled 32-bit machines, which are unlikely to be 
used for manipulating huge volumes of data anyway.

We'll also need to develop some magic for 53-bit JS bindings, which I'm not 
sure about.

- Alexey

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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Alexey Proskuryakov

20 нояб. 2014 г., в 10:45, Filip Pizlo fpi...@apple.com написал(а):

 - uint64_t everywhere. This way, we'll solve practical problems with large 
 resources once and for all. Also, this may prove to be necessary to solve 
 even YouTube/Google Drive uploads, I do not know that yet.
 
 How does this solve the problem of 4GB data on 32-bit systems? 

OK, that was not very thoughtful of me indeed. This option is not a good one.

 Are you saying that because the code that measures file sizes uses a 64-bit 
 type then therefore the code that measures memory object sizes should also 
 use that same type?

I'm not; it seems practical enough to isolate code that deals with local files, 
so they don't need to affect the design.

- Alexey

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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-19 Thread Alexey Proskuryakov

This is not exactly about Vector, but if one uses 
FileReader.prototype.readAsArrayBuffer() on a large file, I think that it 
overflows ArrayBuffer. WebKit actually crashes when uploading multi-gigabyte 
files to YouTube, Google Drive and other similar services, although I haven't 
checked whether it's because of ArrayBuffers, or because of a use of 
int/unsigned in another code path.

I think that we should use size_t everywhere except for perhaps a few key 
places where memory impact is critical (and of course we need explicit checks 
when casting down to an unsigned). Or perhaps the rule can be even simpler, and 
unsigned may never be used for indices and sizes, period.

- Alexey


19 нояб. 2014 г., в 12:32, Filip Pizlo fpi...@apple.com написал(а):

 Whatever we do, the clients of Vector should be consistent about what type 
 they use.  I'm actually fine with Vector internally using unsigned even if 
 the API uses size_t, but right now we have lots of code that uses a mix of 
 size_t and unsigned when indexing into Vectors.  That's confusing.
 
 If I picked one type to use for all Vector indices, it would be unsigned 
 rather than size_t.  Vector being limited to unsigned doesn't imply 4GB 
 unless you do Vectorchar.  Usually we have Vectors of pointer-width things, 
 which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)).  Even in a 
 world where we had more than 32GB of memory to use within a single web 
 process, I would hope that we wouldn't use it all on a single Vector and that 
 if we did, we would treat that one specially for a bunch of other sensible 
 reasons (among them being that allocating a contiguous slab of virtual memory 
 of that size is rather taxing).  So, size_t would buy us almost nothing since 
 if we had a vector grow large enough to need it, we would be having a bad 
 time already.
 
 I wonder: are there cases that anyone remembers where we have tried to use 
 Vector to store more than UINT_MAX things?  Another interesting question is: 
 What's the largest number of things that we store into any Vector?  We could 
 use such a metric to project how big Vectors might get in the future.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:20 PM, Chris Dumez cdu...@apple.com wrote:
 
 Hi all,
 
 I recently started updating the WTF::Vector API to use unsigned types 
 instead of size_t [1][2], because:
 - WTF::Vector is already using unsigned type for size/capacity internally to 
 save memory on 64-bit, causing a mismatch between the API and the internal 
 representation [3]
 - Some reviewers have asked me to use unsigned for loop counters iterating 
 over vectors (which looks unsafe as the Vector API, e.g. size(), returns a 
 size_t).
 - I heard from Joseph that this type mismatch is forcing us (and other 
 projects using WTF) to disable some build time warnings
 - The few people I talked to before making that change said we should do it
 
 However, Alexey recently raised concerns about this change. it doesn't 
 strike him as the right direction. 4Gb is not much, and we should have more 
 of WebKit work with the right data types, not less.”.
 I did not initially realize that this change was controversial, but now that 
 it seems it is, I thought I would raise the question on webkit-dev to see 
 what people think about this.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 
 [1] http://trac.webkit.org/changeset/176275
 [2] http://trac.webkit.org/changeset/176293
 [3] http://trac.webkit.org/changeset/148891
 
 ___
 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


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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-19 Thread Alexey Proskuryakov

That makes good sense for internal implementation, do you think that class API 
should also use a custom type, or should it use size_t?

With Vector though, I don't know how we would differentiate code paths that 
need large allocations from ones that don't. Nearly anything that is exposed as 
a JS API or deals with external world can hit sizes over 4Gb. That's not out of 
reach in most scenarios, not even for resources loaded from network.

- Alexey


19 нояб. 2014 г., в 13:19, Filip Pizlo fpi...@apple.com написал(а):

 ArrayBuffers are very special because they are part of ECMAScript.
 
 We use unsigned for the length, because once upon a time, that would have 
 been the right type; these days the right type would be a 53-bit integer.  
 So, size_t would be wrong.  I believe that ArrayBuffers should be changed to 
 use a very special size type; probably it wouldn't even be a primitive type 
 but a class that carefully checked that you never overflowed 53 bits.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:54 PM, Alexey Proskuryakov a...@webkit.org wrote:
 
 
 This is not exactly about Vector, but if one uses 
 FileReader.prototype.readAsArrayBuffer() on a large file, I think that it 
 overflows ArrayBuffer. WebKit actually crashes when uploading multi-gigabyte 
 files to YouTube, Google Drive and other similar services, although I 
 haven't checked whether it's because of ArrayBuffers, or because of a use of 
 int/unsigned in another code path.
 
 I think that we should use size_t everywhere except for perhaps a few key 
 places where memory impact is critical (and of course we need explicit 
 checks when casting down to an unsigned). Or perhaps the rule can be even 
 simpler, and unsigned may never be used for indices and sizes, period.
 
 - Alexey
 
 
 19 нояб. 2014 г., в 12:32, Filip Pizlo fpi...@apple.com написал(а):
 
 Whatever we do, the clients of Vector should be consistent about what type 
 they use.  I'm actually fine with Vector internally using unsigned even if 
 the API uses size_t, but right now we have lots of code that uses a mix of 
 size_t and unsigned when indexing into Vectors.  That's confusing.
 
 If I picked one type to use for all Vector indices, it would be unsigned 
 rather than size_t.  Vector being limited to unsigned doesn't imply 4GB 
 unless you do Vectorchar.  Usually we have Vectors of pointer-width 
 things, which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)).  
 Even in a world where we had more than 32GB of memory to use within a 
 single web process, I would hope that we wouldn't use it all on a single 
 Vector and that if we did, we would treat that one specially for a bunch of 
 other sensible reasons (among them being that allocating a contiguous slab 
 of virtual memory of that size is rather taxing).  So, size_t would buy us 
 almost nothing since if we had a vector grow large enough to need it, we 
 would be having a bad time already.
 
 I wonder: are there cases that anyone remembers where we have tried to use 
 Vector to store more than UINT_MAX things?  Another interesting question 
 is: What's the largest number of things that we store into any Vector?  We 
 could use such a metric to project how big Vectors might get in the future.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:20 PM, Chris Dumez cdu...@apple.com wrote:
 
 Hi all,
 
 I recently started updating the WTF::Vector API to use unsigned types 
 instead of size_t [1][2], because:
 - WTF::Vector is already using unsigned type for size/capacity internally 
 to save memory on 64-bit, causing a mismatch between the API and the 
 internal representation [3]
 - Some reviewers have asked me to use unsigned for loop counters iterating 
 over vectors (which looks unsafe as the Vector API, e.g. size(), returns a 
 size_t).
 - I heard from Joseph that this type mismatch is forcing us (and other 
 projects using WTF) to disable some build time warnings
 - The few people I talked to before making that change said we should do it
 
 However, Alexey recently raised concerns about this change. it doesn't 
 strike him as the right direction. 4Gb is not much, and we should have 
 more of WebKit work with the right data types, not less.”.
 I did not initially realize that this change was controversial, but now 
 that it seems it is, I thought I would raise the question on webkit-dev to 
 see what people think about this.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 
 [1] http://trac.webkit.org/changeset/176275
 [2] http://trac.webkit.org/changeset/176293
 [3] http://trac.webkit.org/changeset/148891
 
 ___
 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
 
 
 


___
webkit-dev mailing list
webkit-dev

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-19 Thread Alexey Proskuryakov

19 нояб. 2014 г., в 13:58, Filip Pizlo fpi...@apple.com написал(а):

 With Vector though, I don't know how we would differentiate code paths that 
 need large allocations from ones that don't. Nearly anything that is exposed 
 as a JS API or deals with external world can hit sizes over 4Gb. That's not 
 out of reach in most scenarios, not even for resources loaded from network.
 
 Can you provide an example?

Yes. XMLHttpRequest::m_binaryResponseBuilder keeps the downloaded data in a 
Vector, so any time there is much data, something bad will happen. This is a 
case that we should support, and not just crash as we would when we think that 
only exploits would try to use as much memory.

All code that is Blob related also uses Vectors, and of course Blobs can 
legitimately be large.

Crypto code uses Vectors internally for the data.

These and related uses are all over the place - see also Vectors in 
FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, 
plug-in code that loads from network, SharedBuffer etc.

- Alexey

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


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-24 Thread Alexey Proskuryakov

The bug got actually created despite the error, 
https://bugs.webkit.org/show_bug.cgi?id=138043.

- Alexey



24 окт. 2014 г., в 3:54, Philippe Normand ph...@igalia.com написал(а):

 Hi!
 
 I'm using the XML-RPC API (via git-bz) and when attaching a patch to a
 bug I get the following error:
 
 There was an error sending mail from 'bugzilla-daemon#64;webkit.org'
to 'zandobersek#64;gmail.com': 
Couldn't connect to bz.apple.com 
 
 Before the Bugzilla upgrade the smtp server was mail.webkit.org. Any
 chance to restore it?
 
 I would have opened a new bug in bugzilla but this error would prevent
 it :)
 
 Philippe
 
 On Thu, 2014-10-16 at 01:48 -0700, David Kilzer wrote:
 Hi,
 
 
 We’re planning on upgrading Bugzilla (bugs.webkit.org) from 3.2.3 to
 4.2.11 on Thursday, October 16 from 8-10 AM PDT.
 
 
 Sorry for the short notice.  I sent this message from the wrong
 address, and didn't see he bounce message until now.
 
 
 Please let me know if you have questions or concerns.  Thanks!
 
 
 Dave
 
 
 ___
 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

- Alexey


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


Re: [webkit-dev] New EWS status bubbles in Bugzilla

2014-09-30 Thread Alexey Proskuryakov

29 сент. 2014 г., в 23:12, Carlos Garcia Campos carlo...@webkit.org 
написал(а):

 Please try it out, and let me know if something breaks, or is not as
 good as it could be!
 
 Looks great! thanks. I've noticed that now we use red also for patches
 that don't apply. I liked that there was a different color for that
 case, since it's common when a patch depends on another one, and the
 patch itself is not necessarily bad.

I agree that this is a non-obvious case. I chose red because EWS can't say 
anything good about the patch (or anything at all), so it needs extra careful 
attention from a reviewer.

Other options that I considered were:

- Keep it purple, as it was. I restricted purple to indicating internal errors, 
so it should pretty much never happen. Using the same color for the entirely 
different case of a patch that does not apply seems wrong.

- Make it white. That seems to make sense logically, but it has the same 
problem of using a single color for multiple purposes as red does. Also, I 
expect it to be surprising (I posted my patch several hours ago, why is it 
still white?)

- Add a new color. I'm not sure if this case is common enough for the color to 
become generally recognizable.

- Instead of per-queue bubbles, show text like Patch does not apply to trunk. 
Not workable, because queues start at different times, and only some of them 
could fail to apply the patch.

Perhaps most importantly, this case is really no different from failing to 
build due to a dependency on another patch, or to failing some tests for the 
same reason. So I don't think that we can represent dependency on another patch 
with color.

Thinking about this now, we could replace bubbles with text when no queue has 
results (i.e. at least one queue has failed to apply, and those that didn't 
still haven't started processing - we can reasonably expect that they will 
fail, too, and even if they apply cleanly, we can just revert to showing 
bubbles then). I can't think of any situation where this would be misleading or 
difficult to comprehend. Would this resolve your concern? Would you be willing 
to post a patch implementing this?

- Alexey

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


Re: [webkit-dev] New EWS status bubbles in Bugzilla

2014-09-30 Thread Alexey Proskuryakov

On 30 сент. 2014 г., at 0:56, Carlos Garcia Campos carlo...@webkit.org wrote:

 Thinking about this now, we could replace bubbles with text when no
 queue has results (i.e. at least one queue has failed to apply, and
 those that didn't still haven't started processing - we can reasonably
 expect that they will fail, too, and even if they apply cleanly, we
 can just revert to showing bubbles then). I can't think of any
 situation where this would be misleading or difficult to comprehend.
 Would this resolve your concern? Would you be willing to post a patch
 implementing this?
 
 Well, I was just surprised to see the bubbles red because I was used to
 seeing them purple, but I agree the case it's not different to when a
 patch fails to build because of a dependency. So, I'll get used to the
 red :-)

It does seem good for usability though - a computer knows that all the queues 
failed to apply, so why make a human hover each of them to confirm? Posted a 
patch to https://bugs.webkit.org/show_bug.cgi?id=137256.

- Alexey



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


[webkit-dev] New EWS status bubbles in Bugzilla

2014-09-29 Thread Alexey Proskuryakov
Hi,

WebKit Bugzilla has new EWS status bubbles now, which will hopefully make it 
more clear what's going on with a patch. Mysterious yellow bubbles that could 
mean anything were eliminated, and most importantly, there is now detailed 
information presented on hover:



Please try it out, and let me know if something breaks, or is not as good as it 
could be!

- Alexey

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


[webkit-dev] Fooling with EWS and commit queue

2014-09-25 Thread Alexey Proskuryakov
Hi,

I started making changes to the logic of EWS and commit queue, please e-mail me 
if something breaks, or even if something begins to behave more strangely than 
it did before.

- Alexey

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


Re: [webkit-dev] DOMWindow::isCurrentlyDisplayedInFrame does not forbid PostMessageTimer for subframe

2014-09-04 Thread Alexey Proskuryakov
Hi!

Could you please file a bug at bugs.webkit.org? If you have a reproducible test 
case where any bad behavior happens, that would be most useful.

I think that the proposed fix would break a case where we currently match 
Firefox:

main.html:
-
button onclick=f()Click/button
script
function f()
{
   var child = window.open(child.html);
   child.navigator.foo = bar;
   child.onload = function() {
   setTimeout(function() {
   var w = child.frames[0];
   w.navigator.foo = bar
   child.location = about:blank;
   setTimeout(function() {
   alert(w.navigator.foo:  + w.navigator.foo +
   \nw.parent.navigator.foo:  + w.parent.navigator.foo +
   \nchild.navigator.foo:  + child.navigator.foo);
   }, 100);
   }, 100);
   }
}
/script
-

child.html:
-
iframe src=child2.html/iframe
-

child2.html:
-
pHello, world!/p
-

In this test, we successfully access window.navigator of both main frame and 
subframe, even though they are in page cache, and DOMWindow::navigator() has an 
isCurrentlyDisplayedInFrame() check.

There was some unfinished work to make this code more reasonable, but it 
stopped long ago: https://bugs.webkit.org/show_bug.cgi?id=62054, 
https://bugs.webkit.org/show_bug.cgi?id=68849.

The name isCurrentlyDisplayedInFrame is clearly inaccurate, however it's not 
clear to me whether we should be trying to make this function better match what 
it claims to do, given the above. It seems that we should instead rename it, 
and inspect call sites like DOMWindow::postMessageTimerFired for whether they 
are doing the right thing.

- Alexey


03 сент. 2014 г., в 5:29, chenhao chen...@ucweb.com написал(а):

 Hi,
 
 We met one issue related with PostMessageTimer, it may launched while the 
 Page had been moved in Page Cache. After checking the implementation, we 
 doubt this situation should be forbid as below:
 void DOMWindow::postMessageTimerFired(PostMessageTimer timer)
 {
   if (!document() || !isCurrentlyDisplayedInFrame())
   return;
 
 But, unfortunately, isCurrentlyDisplayedInFrame() could not work well with 
 sub-frame, because of the sub-frame and its document would be kept same as 
 before moving in Page Cache, that means the judgement return true always for 
 sub-frame.
 
 So, what I want to do is to judge inPageCache() additionally. Just like below:
 
 bool DOMWindow::isCurrentlyDisplayedInFrame() const
 {
   return m_frame  m_frame-domWindow() == this  
 !m_frame-document()-inPageCache();
 }
 
 That's appreciate to get your comments!
 
 Thanks  Best Regards!
 Hao
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


- Alexey

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


[webkit-dev] WebKit Dashboard metrics

2014-09-02 Thread Alexey Proskuryakov
Hi,

You may have noticed some patches for WebKit Dashboard metrics page landed 
recently. The page is now live at 
http://build.webkit.org/dashboard/metrics.html.

It's a tool that collects historical information from Buildbot and answers 
these questions:

- How much of the time did trunk build successfully?

- How quickly did we fix the build when it got broken?

- How much of the time were all tests green?

- How long did it take for builders to build a patch?

- How long did it take to get results from regression tests after landing a 
patch?


The below results are for Mac bots - you choose which bots to take into 
consideration in the same way it's done on the regular Dashboard, and the 
configuration is actually shared between them.



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


Re: [webkit-dev] WebKit2 EWS bots are sick

2014-08-25 Thread Alexey Proskuryakov

25 авг. 2014 г., в 1:54, Benjamin Poulain benja...@webkit.org написал(а):

 It looks like the WebKit2 EWS bots are having a bad time. They keep
 timing out on a bunch of tests. Can anyone restart them?

The bots restart themselves frequently. Looks like there must be a real problem 
that makes them fail - I briefly looked into it, but couldn't find any leads.

On the patches I checked into, EWS was spuriously reporting crashes, e.g. 
https://webkit-queues.appspot.com/results/5478465239252992. There were no 
crash logs on the bot, so these are not real crashes.

- Alexey

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


Re: [webkit-dev] Mac WK2 EWS bots having issues

2014-08-01 Thread Alexey Proskuryakov

30 июля 2014 г., в 11:17, Alexey Proskuryakov a...@webkit.org написал(а):

 https://bugs.webkit.org/show_bug.cgi?id=135418
 media/track/add-and-remove-track.html and media/media-fragments/TC0001.html 
 are flaky on Mac WK2 EWS, asserting under 
 TestRunner::removeAllWebNotificationPermissions

This is now fixed, and Mac WK2 EWS appears to be in good shape.

- Alexey



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


Re: [webkit-dev] Mac WK2 EWS bots having issues

2014-07-30 Thread Alexey Proskuryakov

30 июля 2014 г., в 3:16, Osztrogonác Csaba o...@inf.u-szeged.hu написал(а):

 If there is no volunteer for fixing it in the near future,
 I'm going to propose a patch making the Mac WK2 EWS not
 comment bugzilla and set cq- for random patches.

I've been already looking into this, and fixed some issues. Admittedly, this 
wasn't enough.

We need Mac WK2 EWS to keep uploading results to Bugzilla, as otherwise there 
is no way to know what failed, and no way to fix it. The failures seen by EWS 
bots are different from what testers see.

- Alexey

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


Re: [webkit-dev] Mac WK2 EWS bots having issues

2014-07-30 Thread Alexey Proskuryakov

30 июля 2014 г., в 3:16, Osztrogonác Csaba o...@inf.u-szeged.hu написал(а):

 You can check the SPAM history with this bugzilla query: http://goo.gl/qepg2l 
 (30 days history)

Thank you for posting this. What's interesting is that right now, the latest 
result is accurate, the patch actually breaks a test.

I looked through erroneous results, and it appears that there is essentially a 
single issue here, which I filed:

https://bugs.webkit.org/show_bug.cgi?id=135418
media/track/add-and-remove-track.html and media/media-fragments/TC0001.html are 
flaky on Mac WK2 EWS, asserting under 
TestRunner::removeAllWebNotificationPermissions

- Alexey


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


Re: [webkit-dev] Mixed content checking

2014-07-24 Thread Alexey Proskuryakov

23 июля 2014 г., в 17:08, Michael Catanzaro mcatanz...@igalia.com написал(а):

 One problem with these settings is that frames are treated as mixed
 passive content rather than mixed active content. For the WebKitGTK+ API
 I want frames to be treated as active content, which is what most major
 browsers currently do.

Thank you for the heads up!

Can you elaborate on why this is desirable? A non-https frame always has a 
different origin, so it can't script the main frame.

In other words, how is active content defined here?

 I'm also planning to block mixed XMLHttpRequest and WebSocket
 connections when allow-running-of-insecure-content is false. 

Same question, why? Cross origin XMLHttpRequest is different from cross origin 
scripts in that it takes quite a bit of effort to make it work, so it's not the 
same case of accidentally loading a subresource using http instead of https.

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


Re: [webkit-dev] Mac WK2 EWS bots having issues

2014-07-15 Thread Alexey Proskuryakov

Some of the bugs tracking the issues are 
https://bugs.webkit.org/show_bug.cgi?id=122475 and 
https://bugs.webkit.org/show_bug.cgi?id=134793.

- Alexey



14 июля 2014 г., в 7:23, Osztrogonác Csaba o...@inf.u-szeged.hu написал(а):

 Hi,
 
 It seems the Mac WK2 EWS bots are very flakey nowadays, they set cq-
 and comment bugzilla due to false positive media/* test failures.
 
 Is there any volunteer for fixing them?
 
 Ossy

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


Re: [webkit-dev] Comment on the bug email author/reviewer before reverting a patch

2014-07-11 Thread Alexey Proskuryakov
(re-sent from correct address)

11 июля 2014 г., в 3:59, Maciej Stachowiak m...@apple.com написал(а):

 So it seems like the extra request for people using “webkitbot rollout” is to 
 add diagnostic information to the rollout bug, and wait a reasonable period 
 before cq+ing it. Is that something everyone could live with?


In the past, I've seen people overlook comments in rollout bugs more frequently 
than in original bugs, so I usually added the diagnostic information to the 
original bug. I think that it's more relevant there, as that's where people 
will be continuing the work. Knowing what the failure symptoms were is 
certainly relevant when reviewing a new iteration of the patch.

I have a potential issue with reasonable period. In the thread, someone 
mentioned ~3 hours as the time to wait. But having brokenness for a good part 
of a business day is unhelpful even if it's only one thing that's broken at a 
given time. Regressions are introduced more frequently than one per three hours 
on average, so a grace period this long will result in never having green tests 
(here I assume that no one advocates for any sort of grace period for build 
failures).

My strong preference is immediate reaction. It doesn't always have to be a 
rollout, sometimes an issue can be fixed, or some tests can even be temporarily 
skipped - just make the tree green and stable for everyone else, as quickly as 
possible. But if the author is not available, and the bot watcher doesn't have 
a better fix (or is simply overwhelmed with multiple regressions being under 
investigation at once), I think that immediate rollout should be considered 
normal.

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


  1   2   3   4   5   >