Re: [webkit-dev] Unmaintained feature list

[Hayato Ito]

I've added 'contributors: none' to SHADOW_DOM.

It looks like you merged two lists just before I updated
http://trac.webkit.org/wiki/UnmaintainedFeatureList. :)

On Tue, Apr 9, 2013 at 11:33 AM, Ryosuke Niwa  wrote:
> On Mon, Apr 8, 2013 at 4:03 PM, Glenn Adams  wrote:
>>
>>
>> On Mon, Apr 8, 2013 at 5:01 PM, Ryosuke Niwa  wrote:
>>>
>>> On Mon, Apr 8, 2013 at 3:59 PM, Glenn Adams  wrote:


 On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:
>
>
> On Apr 7, 2013, at 6:35 PM, Benjamin Poulain 
> wrote:
>
> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  wrote:
>>
>> The recent request from Andreas to remove CSS Variables leads to the
>> question if there are more features that are not maintained at the 
>> moment.
>>
>> I think it would be honest and transparent if we collect all features
>> that are not maintained at the moment in a Wiki page. This would give us 
>> the
>> chance to review each feature individually and we would still have the
>> overview over all features in question. It also makes it a lot easier to
>> plan with the available resources IMO.
>
>
> Sounds like a great idea:
> http://trac.webkit.org/wiki/UnmaintainedFeatureList
>
>
> This is awesome. In addition to features and ports enabling them, it
> might be useful to include an estimate of maintenance burden. In cases 
> where
> organizations are comfortable saying so, it might also be useful to 
> express
> short-term future interest in enabling the feature if they don't have it 
> on
> already.


 I have taken the liberty to add a complementary list at
 http://trac.webkit.org/wiki/MaintainedFeatureList where contributors can
 register their commitment to maintaining features.
>>>
>>>
>>> We should somehow merge these two lists into
>>> http://trac.webkit.org/wiki/FeatureFlags.
>>
>>
>> +1
>
>
> Merged. For feature flags that didn't have any "maintainers", I've added
> "contributors: none."
>
> - R. Niwa
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>



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

Re: [webkit-dev] Chromium bugs marked as WontFix

[Ryosuke Niwa]

Thanks for the cleanup!

- R. Niwa

On Mon, Apr 8, 2013 at 4:03 PM, Stephen Chenney wrote:

> I am making a pass to mark Chromium-specific bugs as WontFix in WebKit
> while adding Chromium bugs as appropriate. This is generating lots of
> email, which is unfortunate but unavoidable.
>
> Should you get notification of a bug you care about, and wish to track it
> in Chromium, please go to crbug.com and search for
> "label:WebKit-ID-X" where XX is the WK bug number. It will take you
> to the migrated bug.
>
> If you have a pending patch that you wish to land, then (in your Blink
> root directory) run webkit-patch apply-attachment as you would in WebKit.
> You can then upload for Chromium review.
>
> Stephen.
>
> ___
> 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] Unmaintained feature list

[Ryosuke Niwa]

On Mon, Apr 8, 2013 at 4:03 PM, Glenn Adams  wrote:

>
> On Mon, Apr 8, 2013 at 5:01 PM, Ryosuke Niwa  wrote:
>
>> On Mon, Apr 8, 2013 at 3:59 PM, Glenn Adams  wrote:
>>
>>>
>>> On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:
>>>

 On Apr 7, 2013, at 6:35 PM, Benjamin Poulain 
 wrote:

 On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  wrote:

> The recent request from Andreas to remove CSS Variables leads to the
> question if there are more features that are not maintained at the moment.
>
> I think it would be honest and transparent if we collect all features
> that are not maintained at the moment in a Wiki page. This would give us
> the chance to review each feature individually and we would still have the
> overview over all features in question. It also makes it a lot easier to
> plan with the available resources IMO.
>

 Sounds like a great idea:
 http://trac.webkit.org/wiki/UnmaintainedFeatureList


 This is awesome. In addition to features and ports enabling them, it
 might be useful to include an estimate of maintenance burden. In cases
 where organizations are comfortable saying so, it might also be useful to
 express short-term future interest in enabling the feature if they don't
 have it on already.

>>>
>>> I have taken the liberty to add a complementary list at
>>> http://trac.webkit.org/wiki/MaintainedFeatureList where contributors
>>> can register their commitment to maintaining features.
>>>
>>
>> We should somehow merge these two lists into
>> http://trac.webkit.org/wiki/FeatureFlags.
>>
>
> +1
>

Merged. For feature flags that didn't have any "maintainers", I've added
"contributors: none."

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

Re: [webkit-dev] Ruby in WebKit

[Tim Mahoney]

On Apr 8, 2013, at 12:00 PM, Filip Pizlo  wrote:

> ...WebKit is unlikely to unilaterally add support for a different language, 
> unless there was support in standards bodies and/or consensus from other 
> browser vendors.

That's understandable. I wonder if browser vendors would be interested if there 
was enough demand for it.

On Apr 8, 2013, at 12:00 PM, Benjamin Poulain  wrote:

> Seriously, this was already discussed in the past. See this thread: 
> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018775.html
> The consensus is that supporting non-standard languages would hurt the web, 
> and that is a bad direction for the project.

Thanks for the link. There are some great points in that thread. 
Maintainability, security, stability, and standardization are all valid reasons 
to worry. If only one browser implemented Ruby or Python or whatever language, 
then we would be in a bad situation.

> The direction of WebKit seems to be toward integrating JavaScriptCore more 
> closely with WebCore. This may make your project a little bit harder to 
> maintain.

That's another point I'm worried about. Is there any documentation or 
discussion on exactly how JSC will be integrated more closely to WebCore? I 
think my head is too wrapped up in the current bindings to imagine how this 
might be done.

Thanks,
-Tim

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

Re: [webkit-dev] Buildsystem cleanup

[Mark Rowe]

On 2013-04-08, at 17:45, Patrick Gansterer  wrote:

> 
> Am 09.04.2013 um 02:29 schrieb Mark Rowe:
> 
>> 
>> On 2013-04-08, at 17:16, Patrick Gansterer  wrote:
>> 
>>> 
>>> Am 09.04.2013 um 00:58 schrieb Mark Rowe:
>>> 
 
 On 2013-04-08, at 15:44, Patrick Gansterer  wrote:
 
> 
> Am 08.04.2013 um 21:26 schrieb Roger Fong:
> 
>> Unfortunately this would cause a lot of complication in our internal 
>> build setup that we currently don’t really have the resources to deal 
>> with right now.
> 
> Please don't get me wrong, but I only get a "some internal problems" 
> answer always. Can someone please give some more detailed answer on the 
> internal requirements. I'm willing to do the work for the Windows ports, 
> but I need more information. How is the Windows port built at Apple? Is 
> it possible to switch it to a CMake generated project? 
 
 The biggest complicating factor is that when each project builds it only 
 has access to its own source, and the built products from earlier 
 projects. This was mentioned the last time you suggested switching to 
 CMake for the Windows build: 
 .
>>> 
>>> I know the last thread, so please don't hurt me if I ask dumb questions, 
>>> but how does it work at the moment? ;-)
>>> What is the root directory of a checkout? E.g. if I checkout only 
>>> Source/JavaScriptCore how can I access the vsprops files from 
>>> WebKitLibraries/win?
>> 
>> WebKitLibraries/win/tools is treated as its own project. It is built first 
>> so that the other WebKit projects can use the files that it installs. You 
>> can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the 
>> installation.
> 
> So having an additional top level directory with all shares CMake files is 
> possible?

It should be, yes.

> How are the ENABLE_* feature defines handled? Are they part of this files too?

I think that’s what the WebKitLibraries/win/tools/vsprops/FeatureDefines* is 
about, yes.

>>> If there is a checkout of the whole tree for every target, how do you make 
>>> sure that the files from the previous build are use (and not from the 
>>> checkout)?
>> 
>> Only a subset of the tree is available. For instance, when preparing to 
>> build JavaScriptCore the relevant source is fetched using “svn export 
>> https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The 
>> resulting directory is then provided to the build machine.
> 
> Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can 
> have a look at it then to check if I understand the concept correctly before 
> I move on to WebCore + WebKit?

Sounds good.

> 
>>> Beside this, is there a general problem with CMake for the Windows port? 
>>> For the Mac port there is the problem, that CMake is not an executable 
>>> provided by the system (maybe i can some time...). Since many other tools 
>>> are require separate installation  on Windows anyway there should be no 
>>> problem in installing CMake too?
>> 
>> Making the CMake executable available shouldn’t be a problem.
>> 
>> Do the projects generated by CMake suffer from the same problem with 
>> absolute paths as CMake’s Xcode projects? I’m not sure whether that would be 
>> a problem for us on Windows, but it’s good to understand any limitations 
>> ahead of time.
> 
> What is the concrete "problem" with the absolute paths? It's true that you 
> can't copy a generated vcproj to an other location, but that shouldn't be 
> required when you have installed CMake on that machine. And since the CMake 
> executable is required by the generated build files (in the background for 
> platform abstraction) it makes not much sense in a CMake workflow anyway. You 
> usually just run "cd build_dir && cmake path/to/source && cmake --build ." 
> and get all your files built.

I mentioned it because it's an obvious point that’s different than how our 
existing build systems work and so it has the potential to cause unexpected 
problems. I’m not aware of any actual issues that it will cause (beyond 
offending my sensibilities).

- Mark

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

Re: [webkit-dev] Buildsystem cleanup

[Patrick Gansterer]

Am 09.04.2013 um 02:29 schrieb Mark Rowe:

> 
> On 2013-04-08, at 17:16, Patrick Gansterer  wrote:
> 
>> 
>> Am 09.04.2013 um 00:58 schrieb Mark Rowe:
>> 
>>> 
>>> On 2013-04-08, at 15:44, Patrick Gansterer  wrote:
>>> 
 
 Am 08.04.2013 um 21:26 schrieb Roger Fong:
 
> Unfortunately this would cause a lot of complication in our internal 
> build setup that we currently don’t really have the resources to deal 
> with right now.
 
 Please don't get me wrong, but I only get a "some internal problems" 
 answer always. Can someone please give some more detailed answer on the 
 internal requirements. I'm willing to do the work for the Windows ports, 
 but I need more information. How is the Windows port built at Apple? Is it 
 possible to switch it to a CMake generated project? 
>>> 
>>> The biggest complicating factor is that when each project builds it only 
>>> has access to its own source, and the built products from earlier projects. 
>>> This was mentioned the last time you suggested switching to CMake for the 
>>> Windows build: 
>>> .
>> 
>> I know the last thread, so please don't hurt me if I ask dumb questions, but 
>> how does it work at the moment? ;-)
>> What is the root directory of a checkout? E.g. if I checkout only 
>> Source/JavaScriptCore how can I access the vsprops files from 
>> WebKitLibraries/win?
> 
> WebKitLibraries/win/tools is treated as its own project. It is built first so 
> that the other WebKit projects can use the files that it installs. You can 
> see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the 
> installation.

So having an additional top level directory with all shares CMake files is 
possible? How are the ENABLE_* feature defines  handled? Are they part of this 
files too?

>> Is there a checkout of this "global" files for the individual targets too?
> 
> No.

But they are "installed" via a previous build, so mainly the same. ;-)

>> If there is a checkout of the whole tree for every target, how do you make 
>> sure that the files from the previous build are use (and not from the 
>> checkout)?
> 
> Only a subset of the tree is available. For instance, when preparing to build 
> JavaScriptCore the relevant source is fetched using “svn export 
> https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The 
> resulting directory is then provided to the build machine.

Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have 
a look at it then to check if I understand the concept correctly before I move 
on to WebCore + WebKit?

>> Beside this, is there a general problem with CMake for the Windows port? For 
>> the Mac port there is the problem, that CMake is not an executable provided 
>> by the system (maybe i can some time...). Since many other tools are require 
>> separate installation  on Windows anyway there should be no problem in 
>> installing CMake too?
> 
> Making the CMake executable available shouldn’t be a problem.
> 
> Do the projects generated by CMake suffer from the same problem with absolute 
> paths as CMake’s Xcode projects? I’m not sure whether that would be a problem 
> for us on Windows, but it’s good to understand any limitations ahead of time.

What is the concrete "problem" with the absolute paths? It's true that you 
can't copy a generated vcproj to an other location, but that shouldn't be 
required when you have installed CMake on that machine. And since the CMake 
executable is required by the generated build files (in the background for 
platform abstraction) it makes not much sense in a CMake workflow anyway. You 
usually just run "cd build_dir && cmake path/to/source && cmake --build ." and 
get all your files built.

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

Re: [webkit-dev] Buildsystem cleanup

[Mark Rowe]

On 2013-04-08, at 17:16, Patrick Gansterer  wrote:

> 
> Am 09.04.2013 um 00:58 schrieb Mark Rowe:
> 
>> 
>> On 2013-04-08, at 15:44, Patrick Gansterer  wrote:
>> 
>>> 
>>> Am 08.04.2013 um 21:26 schrieb Roger Fong:
>>> 
 Unfortunately this would cause a lot of complication in our internal build 
 setup that we currently don’t really have the resources to deal with right 
 now.
>>> 
>>> Please don't get me wrong, but I only get a "some internal problems" answer 
>>> always. Can someone please give some more detailed answer on the internal 
>>> requirements. I'm willing to do the work for the Windows ports, but I need 
>>> more information. How is the Windows port built at Apple? Is it possible to 
>>> switch it to a CMake generated project? 
>> 
>> The biggest complicating factor is that when each project builds it only has 
>> access to its own source, and the built products from earlier projects. This 
>> was mentioned the last time you suggested switching to CMake for the Windows 
>> build: 
>> .
> 
> I know the last thread, so please don't hurt me if I ask dumb questions, but 
> how does it work at the moment? ;-)
> What is the root directory of a checkout? E.g. if I checkout only 
> Source/JavaScriptCore how can I access the vsprops files from 
> WebKitLibraries/win?

WebKitLibraries/win/tools is treated as its own project. It is built first so 
that the other WebKit projects can use the files that it installs. You can see 
a Makefile at WebKitLibraries/win/tools/WinTools.make that does the 
installation.

> Is there a checkout of this "global" files for the individual targets too?

No.

> If there is a checkout of the whole tree for every target, how do you make 
> sure that the files from the previous build are use (and not from the 
> checkout)?

Only a subset of the tree is available. For instance, when preparing to build 
JavaScriptCore the relevant source is fetched using “svn export 
https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The 
resulting directory is then provided to the build machine.

> Beside this, is there a general problem with CMake for the Windows port? For 
> the Mac port there is the problem, that CMake is not an executable provided 
> by the system (maybe i can some time...). Since many other tools are require 
> separate installation  on Windows anyway there should be no problem in 
> installing CMake too?

Making the CMake executable available shouldn’t be a problem.

Do the projects generated by CMake suffer from the same problem with absolute 
paths as CMake’s Xcode projects? I’m not sure whether that would be a problem 
for us on Windows, but it’s good to understand any limitations ahead of time.

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

Re: [webkit-dev] Buildsystem cleanup

[Patrick Gansterer]

Am 09.04.2013 um 00:58 schrieb Mark Rowe:

> 
> On 2013-04-08, at 15:44, Patrick Gansterer  wrote:
> 
>> 
>> Am 08.04.2013 um 21:26 schrieb Roger Fong:
>> 
>>> Unfortunately this would cause a lot of complication in our internal build 
>>> setup that we currently don’t really have the resources to deal with right 
>>> now.
>> 
>> Please don't get me wrong, but I only get a "some internal problems" answer 
>> always. Can someone please give some more detailed answer on the internal 
>> requirements. I'm willing to do the work for the Windows ports, but I need 
>> more information. How is the Windows port built at Apple? Is it possible to 
>> switch it to a CMake generated project? 
> 
> The biggest complicating factor is that when each project builds it only has 
> access to its own source, and the built products from earlier projects. This 
> was mentioned the last time you suggested switching to CMake for the Windows 
> build: .

I know the last thread, so please don't hurt me if I ask dumb questions, but 
how does it work at the moment? ;-)
What is the root directory of a checkout? E.g. if I checkout only 
Source/JavaScriptCore how can I access the vsprops files from 
WebKitLibraries/win? Is there a checkout of this "global" files for the 
individual targets too? If there is a checkout of the whole tree for every 
target, how do you make sure that the files from the previous build are use 
(and not from the checkout)?
Maybe someone can explain the details a little bit more, so I can understand 
the requirements?

Beside this, is there a general problem with CMake for the Windows port? For 
the Mac port there is the problem, that CMake is not an executable provided by 
the system (maybe i can some time...). Since many other tools are require 
separate installation  on Windows anyway there should be no problem in 
installing CMake too?

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

Re: [webkit-dev] Buildsystem cleanup

[Tim Horton]

On Apr 8, 2013, at 3:44 PM, Patrick Gansterer  wrote:

>> I wasn’t aware that the build worked without a VS2010 pThreads build. I was 
>> running into issues because of the pThreads dll having embedded manifest 
>> problems earlier. Did you do anything special to circumvent that issue?
> 
> I committed many patches to get rid of pthread as a whole on Windows in the 
> past. Maybe I use a special flag which disables the "remaining" pthread calls 
> on Windows.
> 
>> It won’t take much to switch it over but the problem was originally that I 
>> couldn’t get it to build without a newer compile of the pthreads library. 
>> Thus we were waiting for the pthreads folks to release a newer pthreads dll 
>> before doing the switch over.
> 
> Why not just remove the remaining pthread calls on Windows (if there are) and 
> disable USE(PTHREADS)? I'm willing to do the work here too, to get rid of 
> pthreads on Windows.

Regardless of the cmake issue, ^^ this seems like a valid and useful project.


> -- Patrick
> ___
> 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] Unmaintained feature list

[Glenn Adams]

On Mon, Apr 8, 2013 at 5:01 PM, Ryosuke Niwa  wrote:

> On Mon, Apr 8, 2013 at 3:59 PM, Glenn Adams  wrote:
>
>>
>> On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:
>>
>>>
>>> On Apr 7, 2013, at 6:35 PM, Benjamin Poulain 
>>> wrote:
>>>
>>> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  wrote:
>>>
 The recent request from Andreas to remove CSS Variables leads to the
 question if there are more features that are not maintained at the moment.

 I think it would be honest and transparent if we collect all features
 that are not maintained at the moment in a Wiki page. This would give us
 the chance to review each feature individually and we would still have the
 overview over all features in question. It also makes it a lot easier to
 plan with the available resources IMO.

>>>
>>> Sounds like a great idea:
>>> http://trac.webkit.org/wiki/UnmaintainedFeatureList
>>>
>>>
>>> This is awesome. In addition to features and ports enabling them, it
>>> might be useful to include an estimate of maintenance burden. In cases
>>> where organizations are comfortable saying so, it might also be useful to
>>> express short-term future interest in enabling the feature if they don't
>>> have it on already.
>>>
>>
>> I have taken the liberty to add a complementary list at
>> http://trac.webkit.org/wiki/MaintainedFeatureList where contributors can
>> register their commitment to maintaining features.
>>
>
> We should somehow merge these two lists into
> http://trac.webkit.org/wiki/FeatureFlags.
>

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

[webkit-dev] Chromium bugs marked as WontFix

[Stephen Chenney]

I am making a pass to mark Chromium-specific bugs as WontFix in WebKit
while adding Chromium bugs as appropriate. This is generating lots of
email, which is unfortunate but unavoidable.

Should you get notification of a bug you care about, and wish to track it
in Chromium, please go to crbug.com and search for "label:WebKit-ID-X"
where XX is the WK bug number. It will take you to the migrated bug.

If you have a pending patch that you wish to land, then (in your Blink root
directory) run webkit-patch apply-attachment as you would in WebKit. You
can then upload for Chromium review.

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

Re: [webkit-dev] Unmaintained feature list

[Ryosuke Niwa]

On Mon, Apr 8, 2013 at 3:59 PM, Glenn Adams  wrote:

>
> On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:
>
>>
>> On Apr 7, 2013, at 6:35 PM, Benjamin Poulain  wrote:
>>
>> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  wrote:
>>
>>> The recent request from Andreas to remove CSS Variables leads to the
>>> question if there are more features that are not maintained at the moment.
>>>
>>> I think it would be honest and transparent if we collect all features
>>> that are not maintained at the moment in a Wiki page. This would give us
>>> the chance to review each feature individually and we would still have the
>>> overview over all features in question. It also makes it a lot easier to
>>> plan with the available resources IMO.
>>>
>>
>> Sounds like a great idea:
>> http://trac.webkit.org/wiki/UnmaintainedFeatureList
>>
>>
>> This is awesome. In addition to features and ports enabling them, it
>> might be useful to include an estimate of maintenance burden. In cases
>> where organizations are comfortable saying so, it might also be useful to
>> express short-term future interest in enabling the feature if they don't
>> have it on already.
>>
>
> I have taken the liberty to add a complementary list at
> http://trac.webkit.org/wiki/MaintainedFeatureList where contributors can
> register their commitment to maintaining features.
>

We should somehow merge these two lists into
http://trac.webkit.org/wiki/FeatureFlags.

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

Re: [webkit-dev] Unmaintained feature list

[Glenn Adams]

On Mon, Apr 8, 2013 at 4:28 PM, Maciej Stachowiak  wrote:

>
> On Apr 7, 2013, at 6:35 PM, Benjamin Poulain  wrote:
>
> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  wrote:
>
>> The recent request from Andreas to remove CSS Variables leads to the
>> question if there are more features that are not maintained at the moment.
>>
>> I think it would be honest and transparent if we collect all features
>> that are not maintained at the moment in a Wiki page. This would give us
>> the chance to review each feature individually and we would still have the
>> overview over all features in question. It also makes it a lot easier to
>> plan with the available resources IMO.
>>
>
> Sounds like a great idea:
> http://trac.webkit.org/wiki/UnmaintainedFeatureList
>
>
> This is awesome. In addition to features and ports enabling them, it might
> be useful to include an estimate of maintenance burden. In cases where
> organizations are comfortable saying so, it might also be useful to express
> short-term future interest in enabling the feature if they don't have it on
> already.
>

I have taken the liberty to add a complementary list at
http://trac.webkit.org/wiki/MaintainedFeatureList where contributors can
register their commitment to maintaining features.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Buildsystem cleanup

[Mark Rowe]

On 2013-04-08, at 15:44, Patrick Gansterer  wrote:

> 
> Am 08.04.2013 um 21:26 schrieb Roger Fong:
> 
>> Unfortunately this would cause a lot of complication in our internal build 
>> setup that we currently don’t really have the resources to deal with right 
>> now.
> 
> Please don't get me wrong, but I only get a "some internal problems" answer 
> always. Can someone please give some more detailed answer on the internal 
> requirements. I'm willing to do the work for the Windows ports, but I need 
> more information. How is the Windows port built at Apple? Is it possible to 
> switch it to a CMake generated project? 

The biggest complicating factor is that when each project builds it only has 
access to its own source, and the built products from earlier projects. This 
was mentioned the last time you suggested switching to CMake for the Windows 
build: .

- Mark

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

Re: [webkit-dev] Buildsystem cleanup

[Patrick Gansterer]

Am 08.04.2013 um 21:26 schrieb Roger Fong:

> Unfortunately this would cause a lot of complication in our internal build 
> setup that we currently don’t really have the resources to deal with right 
> now.

Please don't get me wrong, but I only get a "some internal problems" answer 
always. Can someone please give some more detailed answer on the internal 
requirements. I'm willing to do the work for the Windows ports, but I need more 
information. How is the Windows port built at Apple? Is it possible to switch 
it to a CMake generated project? My last deeper discussion with aroben (!) is 
already a long time ago, but his answer was that beside installing CMake on the 
machines building the code, there is no real blocker. Is this still valid or 
was this never right.

> It would be nice to unite all the build systems at some point in the future 
> but we’re going to push this one off for now.

Yes, but we need to start at some point. Only dreaming about it is not enough. 
I'm willing to do the work, but I need at least some information. I don't want 
to do the work if it is not accepted as in 
https://bugs.webkit.org/show_bug.cgi?id=73100. 

> Also we’re planning on getting rid of the VS2005 eventually.

Eventually? How long do we want to maintain two VS versions in the tree?


Am 08.04.2013 um 22:34 schrieb Roger Fong:

> I wasn’t aware that the build worked without a VS2010 pThreads build. I was 
> running into issues because of the pThreads dll having embedded manifest 
> problems earlier. Did you do anything special to circumvent that issue?

I committed many patches to get rid of pthread as a whole on Windows in the 
past. Maybe I use a special flag which disables the "remaining" pthread calls 
on Windows.

> It won’t take much to switch it over but the problem was originally that I 
> couldn’t get it to build without a newer compile of the pthreads library. 
> Thus we were waiting for the pthreads folks to release a newer pthreads dll 
> before doing the switch over.

Why not just remove the remaining pthread calls on Windows (if there are) and 
disable USE(PTHREADS)? I'm willing to do the work here too, to get rid of 
pthreads on Windows.

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

Re: [webkit-dev] Sunsetting committership and reviewership

[Maciej Stachowiak]

On Apr 7, 2013, at 5:53 PM, Benjamin Poulain  wrote:

> On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher  wrote:
> I think 6 months is fine for deactivating SVN accounts. And a full revoke of 
> reviewer status after 2 years of no activity sounds reasonable to me. We 
> could make it easier to get reviewer status again after a 2 year sunset if 
> the person becomes active again and shows good judgment still.
> 
> +1 to this.
> 
> I think 2 years to revoke reviewer rights is too long. All the drive-by 
> reviews that have caused problems were from reviewers that were inactive for 
> less than 2 years. Nevertheless, 2 years is better than the current situation 
> so it is a good start.

We sometimes get low-quality drive-by reviews even from people who are active 
at the time. I feel like that's not the right basis for the time cutoff. If we 
do have a sunset period, we should think about it in terms of how long it takes 
to be so out of touch with the current state of the project that there's little 
chance you can give a useful review.

Regards,
Maciej


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

Re: [webkit-dev] [blink-dev] Fwd: Unmaintained feature list

[Maciej Stachowiak]

On Apr 8, 2013, at 11:19 AM, Michelangelo De Simone  wrote:

> [Moved/Reposted to WebKit-Dev]
> 
> On Mon, Apr 8, 2013 at 11:08 AM, Ryosuke Niwa  wrote:
> 
>>> What about adding a "NeedsOwner" keyword to orphan feature bugs,
>>> marking them RESOLVED/LATER?
>> 
>> I would be resistent to add such a keyword given there is no official
>> "owner" for any feature in WebKit.
> 
> Call it however you like, it was just an example (appropriate
> candidate might also be "NeedsPeceAndLove"); the idea is to track
> orphan features that might be appealing to contributors seeking
> opportunities and to give them at least some advantage in taking over.

I don't think we should mark bugs resolved if the code is still in WebKit, the 
bug is not fixed, and we'd accept a fix. If we're looking for volunteers to 
hack on particular areas, I think a wiki page seeking volunteers is likely more 
effective.

Regards,
Maciej

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

Re: [webkit-dev] Unmaintained feature list

[Maciej Stachowiak]

On Apr 7, 2013, at 6:35 PM, Benjamin Poulain  wrote:

> On Sun, Apr 7, 2013 at 6:23 PM, Dirk Schulze  wrote:
> The recent request from Andreas to remove CSS Variables leads to the question 
> if there are more features that are not maintained at the moment.
> 
> I think it would be honest and transparent if we collect all features that 
> are not maintained at the moment in a Wiki page. This would give us the 
> chance to review each feature individually and we would still have the 
> overview over all features in question. It also makes it a lot easier to plan 
> with the available resources IMO.
> 
> Sounds like a great idea: http://trac.webkit.org/wiki/UnmaintainedFeatureList

This is awesome. In addition to features and ports enabling them, it might be 
useful to include an estimate of maintenance burden. In cases where 
organizations are comfortable saying so, it might also be useful to express 
short-term future interest in enabling the feature if they don't have it on 
already.

 As we collect this information, I can imagine a few possible dispositions for 
each feature:

- Make an effort to identify new maintainers quickly (e.g. for features that 
are widely relied upon)
- Remove the feature (e.g. for features that no one has enabled, that no one 
wants to enable soon, and that no one is willing to maintain)
- Keep the feature around for a while in hopes someone steps up

Other possible items to add (not sure of port status in all cases):
- HTML Parser (or have enough people touched it that we're ok at least for 
bugfixing?)
- Subpixel layout
- Modules/mediasource (I believe this is MSE)
- Modules/mediastream (I believe this is WebRTC)

Regards,
Maciej

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

Re: [webkit-dev] Buildsystem cleanup

[Roger Fong]

I wasn’t aware that the build worked without a VS2010 pThreads build. I was 
running into issues because of the pThreads dll having embedded manifest 
problems earlier. Did you do anything special to circumvent that issue?

It won’t take much to switch it over but the problem was originally that I 
couldn’t get it to build without a newer compile of the pthreads library. Thus 
we were waiting for the pthreads folks to release a newer pthreads dll before 
doing the switch over.

Also, I believe Brent Fulgham may have modified build-webkit to set environment 
variables appropriately because the VS2010 solution uses different ones than 
the VS2005 solution. I just have those variables set permanently and just build 
directly from the solution file.
(Need to update those build.webkit.org instructions)

On Apr 8, 2013, at 1:13 PM, Justin Haygood  wrote:

> What would it take to switch build-webkit, et al to the VS2010 build? (VS2010 
> does work manually though, if you run build-webkit at least once, let it fail 
> since it can’t find VS2005/VS2008, and then build it from the solution file)
>  
> From: webkit-dev-boun...@lists.webkit.org 
> [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Roger Fong
> Sent: Monday, April 08, 2013 3:26 PM
> To: Patrick Gansterer
> Cc: WebKit Development
> Subject: Re: [webkit-dev] Buildsystem cleanup
>  
> Unfortunately this would cause a lot of complication in our internal build 
> setup that we currently don’t really have the resources to deal with right 
> now.
>  
> It would be nice to unite all the build systems at some point in the future 
> but we’re going to push this one off for now.
>  
> Also we’re planning on getting rid of the VS2005 eventually.
>  
> On Apr 7, 2013, at 6:47 PM, Patrick Gansterer  wrote:
> 
> 
> Hi,
> 
> since the Chromium code is getting removed step by step I think that the GYP 
> build system won't have a shiny future in the WebKit repository. In the GYP 
> vs. CMake match CMake gets an additional point: There is no WebKit port 
> working with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give 
> CMake a try too.
> Adopting the Mac port does not seam to be an easy task in the near future, 
> because of the very specific build requirements.
> But what about the Windows ports? I updated the patch at [2] to work with a 
> more recent revision. Are there any chances to use CMake instead of the VS 
> solution files? At the moment it becomes even worst, since there are VS2005 
> and VS2010 files in the tree, which duplicated many files.
> The patch at [2] is only an initial example, since a complete implementation 
> would require more changes in the code. If CMake becomes an option, I'm 
> willing to provide an "complete" patch with all CMake files.
> 
> -- Patrick
> 
> [1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html
> [2] https://bugs.webkit.org/show_bug.cgi?id=72816
> ___
> 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] webkit-dev Digest, Vol 95, Issue 11

[Ashley]

Sent from my iPhone

On 8 Apr 2013, at 07:01, webkit-dev-requ...@lists.webkit.org wrote:

> Send webkit-dev mailing list submissions to
>webkit-dev@lists.webkit.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.webkit.org/mailman/listinfo/webkit-dev
> or, via email, send a message with subject or body 'help' to
>webkit-dev-requ...@lists.webkit.org
> 
> You can reach the person managing the list at
>webkit-dev-ow...@lists.webkit.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of webkit-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Fwd:  Feature removal: CSS variables (Ryosuke Niwa)
>   2. Re: Feature removal: CSS variables (Andreas Kling)
>   3. Re: Feature removal: CSS variables (Jon Rimmer)
>   4. Re: Feature removal: CSS variables (Geoffrey Garen)
>   5. Re: Sunsetting committership and reviewership (Gyuyoung Kim)
>   6. Re: Feature removal: CSS variables (Jon Rimmer)
>   7. Fwd:  Feature removal: CSS variables (Ryosuke Niwa)
>   8. Re: Sunsetting committership and reviewership (Timothy Hatcher)
>   9. Re: Sunsetting committership and reviewership (Benjamin Poulain)
>  10. Re: Sunsetting committership and reviewership (Dirk Schulze)
>  11. Unmaintained feature list (Dirk Schulze)
>  12. Re: Sunsetting committership and reviewership (Benjamin Poulain)
>  13. Re: Feature removal: CSS variables (Jon Rimmer)
>  14. Re: Feature removal: CSS variables (Adele Peterson)
>  15. Re: Unmaintained feature list (Benjamin Poulain)
>  16. Re: Feature removal: CSS variables (Jon Rimmer)
>  17. Buildsystem cleanup (Patrick Gansterer)
>  18. Re: Sunsetting committership and reviewership (Glenn Adams)
>  19. Re: Fwd:  Feature removal: CSS variables (Karen Shaeffer)
>  20. Re: Fwd: Feature removal: CSS variables (Benjamin Poulain)
>  21. Re: Sunsetting committership and reviewership (Darin Adler)
>  22. Re: Fwd: Feature removal: CSS variables (Ryosuke Niwa)
> 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Buildsystem cleanup

[Justin Haygood]

What would it take to switch build-webkit, et al to the VS2010 build? (VS2010 
does work manually though, if you run build-webkit at least once, let it fail 
since it can't find VS2005/VS2008, and then build it from the solution file)

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Roger Fong
Sent: Monday, April 08, 2013 3:26 PM
To: Patrick Gansterer
Cc: WebKit Development
Subject: Re: [webkit-dev] Buildsystem cleanup

Unfortunately this would cause a lot of complication in our internal build 
setup that we currently don't really have the resources to deal with right now.

It would be nice to unite all the build systems at some point in the future but 
we're going to push this one off for now.

Also we're planning on getting rid of the VS2005 eventually.

On Apr 7, 2013, at 6:47 PM, Patrick Gansterer 
mailto:par...@paroga.com>> wrote:


Hi,

since the Chromium code is getting removed step by step I think that the GYP 
build system won't have a shiny future in the WebKit repository. In the GYP vs. 
CMake match CMake gets an additional point: There is no WebKit port working 
with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give CMake a 
try too.
Adopting the Mac port does not seam to be an easy task in the near future, 
because of the very specific build requirements.
But what about the Windows ports? I updated the patch at [2] to work with a 
more recent revision. Are there any chances to use CMake instead of the VS 
solution files? At the moment it becomes even worst, since there are VS2005 and 
VS2010 files in the tree, which duplicated many files.
The patch at [2] is only an initial example, since a complete implementation 
would require more changes in the code. If CMake becomes an option, I'm willing 
to provide an "complete" patch with all CMake files.

-- Patrick

[1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html
[2] https://bugs.webkit.org/show_bug.cgi?id=72816
___
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] Buildsystem cleanup

[Roger Fong]

Unfortunately this would cause a lot of complication in our internal build 
setup that we currently don’t really have the resources to deal with right now.

It would be nice to unite all the build systems at some point in the future but 
we’re going to push this one off for now.

Also we’re planning on getting rid of the VS2005 eventually.

On Apr 7, 2013, at 6:47 PM, Patrick Gansterer  wrote:

> Hi,
> 
> since the Chromium code is getting removed step by step I think that the GYP 
> build system won't have a shiny future in the WebKit repository. In the GYP 
> vs. CMake match CMake gets an additional point: There is no WebKit port 
> working with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give 
> CMake a try too.
> Adopting the Mac port does not seam to be an easy task in the near future, 
> because of the very specific build requirements.
> But what about the Windows ports? I updated the patch at [2] to work with a 
> more recent revision. Are there any chances to use CMake instead of the VS 
> solution files? At the moment it becomes even worst, since there are VS2005 
> and VS2010 files in the tree, which duplicated many files.
> The patch at [2] is only an initial example, since a complete implementation 
> would require more changes in the code. If CMake becomes an option, I'm 
> willing to provide an "complete" patch with all CMake files.
> 
> -- Patrick
> 
> [1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html
> [2] https://bugs.webkit.org/show_bug.cgi?id=72816
> ___
> 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] sheriffbot has been renamed to webkitbot

[Ryosuke Niwa]

Hi all,

As a part of transition to move Google-sponsored WebKit infrastructure to
Apple, I've renamed sheriffbot to webkitbot.

Let me know if you see any problems with webkitbot.

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

Re: [webkit-dev] Ruby in WebKit

[Filip Pizlo]

Wow, this is really cool!  Congrats on the hard work!

On Apr 8, 2013, at 11:41 AM, Tim Mahoney  wrote:

> I modified WebKit to support Ruby. It needs more work, and I'd like some 
> comments. 
> 
> You can check it out here:
> http://trydecaf.org
> http://github.com/timahoney/decaf 
> 
> I wrote about some of the major changes here:
> https://github.com/timahoney/decaf/wiki/Changes-to-WebKit
> 
> Have I done anything silly?

:-)  Yes and no.  The non-silly part is that this is an awesome display of 
engineering; the silly part is that adding a new language to the web requires 
convincing a lot of people.  For better or worse, the web already has a 
language. :-/  WebKit is unlikely to unilaterally add support for a different 
language, unless there was support in standards bodies and/or consensus from 
other browser vendors.

> What changes should I make?

Do you want it to get adopted?  Then you probably have a steep, uphill battle 
to convince the Web world that this is the right direction.

> Who's interested in multiple scripting languages?

Personally, I think this is good stuff, and I'm really impressed.  I happen to 
like Ruby a lot.  But I am unsure how much traction this will get.  We probably 
wouldn't want this in WebKit trunk unless we believed that it was the right 
direction for the web, and we probably wouldn't want to add support for a 
non-JS-compatible language unilaterally.

-F

> 
> Thanks,
> Tim
> ___
> 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] Ruby in WebKit

[Benjamin Poulain]

On Mon, Apr 8, 2013 at 11:41 AM, Tim Mahoney  wrote:

> I modified WebKit to support Ruby. It needs more work, and I'd like some
> comments.
>
> You can check it out here:
> http://trydecaf.org
> http://github.com/timahoney/decaf
>
> I wrote about some of the major changes here:
> https://github.com/timahoney/decaf/wiki/Changes-to-WebKit



WebKit already supports  ;)

Seriously, this was already discussed in the past. See this thread:
https://lists.webkit.org/pipermail/webkit-dev/2011-December/018775.html
The consensus is that supporting non-standard languages would hurt the web,
and that is a bad direction for the project.

The direction of WebKit seems to be toward integrating JavaScriptCore more
closely with WebCore. This may make your project a little bit harder to
maintain.

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

Re: [webkit-dev] Unmaintained feature list

[Rafael Weinstein]

I've added HTML Template Element to this list, which is currently
behind a feature flag in webkit.

Modulo bugs that may arise, this feature is complete and has shipped
in Chrome (M26). Note that Microsoft has co-edited the spec and
Mozilla has landed support in nightlies.

If bugs arise that require changes to blink, I'll alert webkit-dev to
see what the disposition to the feature is and whether it makes sense
to also prepare a patch for webkit.

On Mon, Apr 8, 2013 at 10:57 AM, Julien Chaffraix  wrote:
>> Sounds like a great idea:
>> http://trac.webkit.org/wiki/UnmaintainedFeatureList
>
> Thanks for starting this.
>
> Added CSS Grid Layout to the list as I don't think I would be able to
> do merges back. I would be more than happy to remove the code if
> people feel the need.
>
> If anyone wants to take over, I would be more than happy to provide
> any needed assistance. The opened bugs on bugzilla should be an
> accurate representation of the amount of work remaining **
>
> Thanks,
> Julien
>
> ** The specification is still in flux so consider this as an estimate
> not an absolute measurement.
> ___
> 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] Ruby in WebKit

[Tim Mahoney]

I modified WebKit to support Ruby. It needs more work, and I'd like some 
comments. 

You can check it out here:
http://trydecaf.org
http://github.com/timahoney/decaf 

I wrote about some of the major changes here:
https://github.com/timahoney/decaf/wiki/Changes-to-WebKit

Have I done anything silly? What changes should I make?
Who's interested in multiple scripting languages?

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

Re: [webkit-dev] [blink-dev] Fwd: Unmaintained feature list

[Michelangelo De Simone]

[Moved/Reposted to WebKit-Dev]

On Mon, Apr 8, 2013 at 11:08 AM, Ryosuke Niwa  wrote:

>> What about adding a "NeedsOwner" keyword to orphan feature bugs,
>> marking them RESOLVED/LATER?
>
> I would be resistent to add such a keyword given there is no official
> "owner" for any feature in WebKit.

Call it however you like, it was just an example (appropriate
candidate might also be "NeedsPeceAndLove"); the idea is to track
orphan features that might be appealing to contributors seeking
opportunities and to give them at least some advantage in taking over.

> Also, we can always file a new bug to re-implement the feature when time
> comes.

What would be the rationale in this case? This doesn't seem very
convenient to me: tracking past work would save time and work to new
contributors.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unmaintained feature list

[Julien Chaffraix]

> Sounds like a great idea:
> http://trac.webkit.org/wiki/UnmaintainedFeatureList

Thanks for starting this.

Added CSS Grid Layout to the list as I don't think I would be able to
do merges back. I would be more than happy to remove the code if
people feel the need.

If anyone wants to take over, I would be more than happy to provide
any needed assistance. The opened bugs on bugzilla should be an
accurate representation of the amount of work remaining **

Thanks,
Julien

** The specification is still in flux so consider this as an estimate
not an absolute measurement.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Sunsetting committership and reviewership

[Ryosuke Niwa]

On Mon, Apr 8, 2013 at 10:36 AM, Benjamin Poulain wrote:

> On Mon, Apr 8, 2013 at 1:45 AM, Simon Hausmann 
> wrote:
>>
>> And instead of addressing these reviewers directly we are trying to
>> introduce
>> a process to automate this, avoid the confrontation, hope that reviewers
>> accepting bad ideas today will instead expire in the future.
>>
>> It appears to me that this approach is based on the assumption that trust
>> fades away over time. Naturally this perception may differ from person to
>> person.
>>
>
> In my opinion, reviews are not "trust affair", they are a technical
> decision. You seem to think people intentionally review bad thinks, I don't
> agree.
>

> When I mess up a review, it is because of the illusion of knowledge. I
> believed I knew enough about a subject to review a patch, but my knowledge
> was outdated or erroneous. With time, this problem becomes worse. I believe
> I know the code, but I only know the past version of the code.
> With hundreds of patches a day, I think not contributing for 2 years means
> you have an outdated view of the code.
>

+1 to that.

When I make bad reviews (I do!), I don't often realize it until bugs are
filed for regressions or some other more knowledgable reviewers comment on
the bug, pointing out flaws in the patch.

In a way, this is an unsolvable problem because nobody can possibly know
with a 100% certainly if you're qualified to review a patch or not.  I've
reviewed some patches that are clearly outside of my expertise at times
because there were no active reviewers in that area, etc... It's a hard
judgement call. On one hand, we don't want to block patches forever
especially it's a crash or security vulnerability fix. On the other hand,
we shouldn't be reviewing patches just because we want to be nice to our
colleague.

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

Re: [webkit-dev] Sunsetting committership and reviewership

[Benjamin Poulain]

On Mon, Apr 8, 2013 at 1:45 AM, Simon Hausmann wrote:
>
> And instead of addressing these reviewers directly we are trying to
> introduce
> a process to automate this, avoid the confrontation, hope that reviewers
> accepting bad ideas today will instead expire in the future.
>
> It appears to me that this approach is based on the assumption that trust
> fades away over time. Naturally this perception may differ from person to
> person.
>

In my opinion, reviews are not "trust affair", they are a technical
decision. You seem to think people intentionally review bad thinks, I don't
agree.

When I mess up a review, it is because of the illusion of knowledge. I
believed I knew enough about a subject to review a patch, but my knowledge
was outdated or erroneous. With time, this problem becomes worse. I believe
I know the code, but I only know the past version of the code.
With hundreds of patches a day, I think not contributing for 2 years means
you have an outdated view of the code.


...And I am also interested in seeing if such a policy would become a
stimulus for people to review more regularly. :)

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

Re: [webkit-dev] gap in github WebKit mirror?

[Osztrogonác Csaba]

Hi Simon,

http://trac.webkit.org/changeset/147258 changed branches/chromium/1453
http://trac.webkit.org/changeset/147259 changed branches/dfgFourthTier

These commits changed different branches, not the trunk. And only
trunk is in the git mirrors. (git.webkit.org and github mirror too)

Ossy

Simon Hausmann írta:

Hi,

I'm a bit puzzled as I look at my local clone of 
https://github.com/WebKit/webkit.git to see that the commits between r147257 
and r147260 appear to be missing. The web interface appears to indicate that 
this is also the case on github itself.


Does anyone know what could cause this?


Simon

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

[webkit-dev] gap in github WebKit mirror?

[Simon Hausmann]

Hi,

I'm a bit puzzled as I look at my local clone of 
https://github.com/WebKit/webkit.git to see that the commits between r147257 
and r147260 appear to be missing. The web interface appears to indicate that 
this is also the case on github itself.

Does anyone know what could cause this?


Simon

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

Re: [webkit-dev] Fwd: WebKit2 Extending Javascript

[Dominik Röttsches]

On 04/04/2013 10:33 AM, Christian Frost wrote:


My problem is that I have to extend Javascript in WebKit2. That is, I
have to add a set of global variables and functions. Potentially I
also need to add custom classes. However, this doesn't seem to be
possible in WebKit2 since it is not yet supported. Can you help me on
this matter?


If you're looking for adding custom JavaScript API at compile time and 
make it available for all scripting contexts, there is no problem with 
that (and there's not a big difference between WebKit1 and 2 for that 
matter). You can start by familiarizing yourself with an IDL file that's 
similar to your purposes, and look at the related .cpp and *Custom.cpp 
files that implement the API that corresponds to that IDL file.


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

Re: [webkit-dev] Sunsetting committership and reviewership

[Thiago Marcos P. Santos]

On Mon, Apr 8, 2013 at 4:27 AM, Benjamin Poulain wrote:

> On Sun, Apr 7, 2013 at 6:07 PM, Dirk Schulze  wrote:
>>
>>  On Apr 7, 2013, at 5:53 PM, Benjamin Poulain 
>> wrote:
>> > On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher 
>> wrote:
>> > I think 6 months is fine for deactivating SVN accounts. And a full
>> revoke of reviewer status after 2 years of no activity sounds reasonable to
>> me. We could make it easier to get reviewer status again after a 2 year
>> sunset if the person becomes active again and shows good judgment still.
>> >
>> > +1 to this.
>> >
>> > I think 2 years to revoke reviewer rights is too long. All the drive-by
>> reviews that have caused problems were from reviewers that were inactive
>> for less than 2 years. Nevertheless, 2 years is better than the current
>> situation so it is a good start.
>>
>> The question is still how you measure active reviewers/contributors? Is
>> it enough to comment on bugs? Real reviews? Must there be at least one r+
>> in this time? Is an actual commit required?
>>
>> What do we gain from reverting reviewer ship/ committer ship?
>>
>
> There is a problem of people not contributing for a while, not familiar
> with the current code base, who come and review things for their colleagues.
> There are bad ideas accepted by reviewers who are not very active on the
> project.
>
> I don't really see the big deal with revoking reviewer rights. If you come
> back to the project, make a few good patches and show a good understanding
> of the code base, you just get the rights back.
> The owner system with WebKit2 is avoiding this problem in an elegant way.
> It is effectively enforcing two reviews for most patches (one reviewer +
> one review from a owner). As a result, the quality of patches in WebKit2
> has increased appreciably.
>

Elegant is a bold claim (at least how it is implemented on WK2). There are
examples of patches waiting for owners review/comments for months (even
though the patch was already pre-reviewed by someone else). I suppose we
also need another thread to discuss this issue...


> What are your concerns exactly?
>
> Benjamin
>
> PS: Maybe we should have this thread on the reviewer mailing list?
>

Please, let's keep this at least to the committers list.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature removal: CSS variables

[Allan Sandfeld Jensen]

I think this discussion can be simplified a bit. I too is very sceptic about 
just removing features and would prefer we didn't remove features based on 
whether they could be a burden, but based on whether they actually are a 
burden or in the way of something specific we would like to do.

The problem with css variables though is that it is not currently being 
actively developed by anyone in webkit, and that no webkit port or bot have it 
enabled. This means that it is very likely to bitrot. Unless someone either 
starts working actively on it or a port decides to enable it on a bot, it is 
just guaranteed to stop working soon.

I am guessing as a minimum an interested third party could offer to setup a 
bot running Qt (the easiest port to run on standard hardware) with CSS 
variables enabled. 

Without testing, CSS variables are better removed and reintroduced later when 
either the implementation in blink gets better and we can adopt a cleaner 
solution, the standard improves or Mozilla implements it. Whichever happens 
first.

Best regards
`Allan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Sunsetting committership and reviewership

[Simon Hausmann]

On Sunday 7. April 2013 18.27.14 Benjamin Poulain wrote:
> On Sun, Apr 7, 2013 at 6:07 PM, Dirk Schulze  wrote:
> > On Apr 7, 2013, at 5:53 PM, Benjamin Poulain  wrote:
> > > On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher 
> > 
> > wrote:
> > > I think 6 months is fine for deactivating SVN accounts. And a full
> > 
> > revoke of reviewer status after 2 years of no activity sounds reasonable
> > to
> > me. We could make it easier to get reviewer status again after a 2 year
> > sunset if the person becomes active again and shows good judgment still.
> > 
> > > +1 to this.
> > > 
> > > I think 2 years to revoke reviewer rights is too long. All the drive-by
> > 
> > reviews that have caused problems were from reviewers that were inactive
> > for less than 2 years. Nevertheless, 2 years is better than the current
> > situation so it is a good start.
> > 
> > The question is still how you measure active reviewers/contributors? Is it
> > enough to comment on bugs? Real reviews? Must there be at least one r+ in
> > this time? Is an actual commit required?
> > 
> > What do we gain from reverting reviewer ship/ committer ship?
> 
> There is a problem of people not contributing for a while, not familiar
> with the current code base, who come and review things for their colleagues.
> There are bad ideas accepted by reviewers who are not very active on the
> project.

And instead of addressing these reviewers directly we are trying to introduce 
a process to automate this, avoid the confrontation, hope that reviewers 
accepting bad ideas today will instead expire in the future.

It appears to me that this approach is based on the assumption that trust 
fades away over time. Naturally this perception may differ from person to 
person.

I have friends from school that I meet maybe once every two years. Oddly I 
still do trust them as much as I did before we went different ways in our life. 
The trust was earned at some point and for me it only changes on a per-
incident basis.


Simon

P.S.: I'm all in favour of locking unused SVN accounts for security reasons, 
similar to how many of us corporate email users have to change our passwords 
every X months.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev