Re: [webkit-dev] Documentation for WTF/JSC exports?

[Hajime Morrita]

Done: https://trac.webkit.org/wiki/ExportingSymbols
It doesn't looks this helps your WTF move though.

On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel  wrote:
> Thank you.  Mark Rowe was kind enough to resolve
> https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in
> http://trac.webkit.org/changeset/111634.
>
> I've found that some of the "Weak External Symbol" errors from
> http://pastebin.com/dVjV8UiR can be resolved by marking the functions
> in question as "inline", but that doesn't seem like the right fix.
>
> Some others like:
> ERROR: symbol double WTF::strtod<(WTF::AllowTrailingJunkTag)0,
> (WTF::AllowTrailingSpacesTag)0>(char const*, char**)
>
> Are for functions which are not even in headers:
> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651
>
> So it's unclear what's causing those.
>
> Thank you for your attempts at documentation. Perhaps that will make
> clear how these exports are supposed to work. :)
>
> -eric
>
> On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita  wrote:
>> I'll write a draft so that ports' expert can fill missing pieces.
>> --
>> morrita
>>
>> On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel  wrote:
>>> Do we have any documentation for how the current symbol export system
>>> for WTF/JSC is supposed to work?
>>>
>>> I'm hitting errors when trying to move WTF files to their own libwtf.a, 
>>> such as:
>>> https://bugs.webkit.org/show_bug.cgi?id=81838
>>> and
>>> http://pastebin.com/dVjV8UiR
>>>
>>> But looking at 
>>> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h
>>>
>>> It appears most of those macros are never used!  (Like
>>> WTF_EXPORT_CLASS, for example.)
>>>
>>> So when trying to resolve errors such as:
>>> https://bugs.webkit.org/show_bug.cgi?id=81838#c8
>>>
>>> The path is unclear.
>>>
>>> Perhaps there is a wiki somewhere on how this system is supposed to work?
>>>
>>> -eric
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> --
>> morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New Feature - Resource Timing

[James Simonsen]

Sorry for taking so long to get back to this. I'm planning to start working
on it again, so it's time to close the loop here.

The main concern earlier in this thread was the ability to take advantage
of the extra timing information. We forwarded these concerns to the W3C
security group as well as Google's and Microsoft's security teams.

Tony's summary of the discussion on the W3C security list is here:
http://lists.w3.org/Archives/Public/public-web-security/2011Oct/0019.html

Everyone agreed that this spec makes timing attacks more explicit. But,
since the timing attacks are already possible, this is not a concern. The
only concern was that if the prior timing attacks could be patched, then
this new spec would still leave us vulnerable. But, since nobody knows how
to close the existing attacks, this wasn't considered an issue. So, they
all are okay proceeding with Resource Timing.

Are there any other concerns?

As for spec updates... part of the Resource Timing spec was split out and
generalized into the Performance Timeline spec [1]. It provides a uniform
API for accessing the collected timing data. It'll include data from
Navigation Timing, Resource Timing, and User Timing (to be discussed
later). I'll land Performance Timeline before Resource Timing. Ports that
wish to expose these APIs should enable: WEB_TIMING, PERFORMANCE_TIMELINE,
and RESOURCE_TIMING.

James

[1]
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overview.html

On Fri, May 20, 2011 at 12:17 PM, Tony Gentilcore wrote:

> I've forwarded these questions on to the working group:
> http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
>
> In the meantime, we'll hold off on landing anything until we have
> satisfactory answers.
>
> -Tony
>
> On Fri, May 20, 2011 at 6:51 PM, Maciej Stachowiak  wrote:
> >
> > On May 20, 2011, at 10:10 AM, Tony Gentilcore wrote:
> >
> >>> Presumably the embedding application would need to require explicit
> user consent to enable the feature.
> >>
> >> My conclusion was different. Given that the timing based privacy
> >> attacks are demonstrable without the interface, I thought it
> >> reasonable to enable-by-default with a hidden pref to disable. But
> >> this is based on the assumption that we aren't actually exposing any
> >> new private information. Am I missing an exploit here?
> >
> > I understand that we have to keep a balance, and statistical
> fingerprinting is already dismayingly effective without any new features.
> However, "enable[d]-by-default with a hidden pref to disable" sounds like
> an extremely weak approach to protecting user privacy.
> >
> > Is it possible to find experts on the topic of statistical
> fingerprinting, as well as security experts in general, who could review
> this API? Things I'd really like to know are:
> >
> > - Does this feature, as designed, increase the effectiveness of user
> fingerprinting, assuming the user is running something like private
> browsing or incognito mode, or is regularly deleting site data? The
> relevant question here is marginal increase in effectiveness - are things
> worse with this feature than without?
> >
> > - Presumably some known statistical fingerprinting techniques can be
> mitigated, if not always than at least in private browsing mode. If that
> was done, then would this timing feature provide an additional
> fingerprinting vector?
> >
> > - Could this feature directly reveal otherwise hard-to-guess information
> about users?
> >
> > - Can this feature be used to aid timing-based security attacks?
> >
> > I would really like to see this kind of review done ahead of time and
> delivered to the Working Group. My worry here is that the feature may have
> fatal flaws as currently designed, or perhaps even in the basic concept of
> its functionality. If that's the case, then we'd certainly want to find out
> before we get locked into it. Perhaps some of the privacy risks can even be
> mitigated, such as by returning fake or random data in private browsing
> mode. I can ask some of Apple's security experts to review with a mind to
> these questions, but I'm wondering if there are other independent experts
> we could ask.
> >
> > My preference would be to tread very carefully around anything that
> could be perceived as a privacy risk.
> >
> > Regards,
> > Maciej
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving WTF out of JavaScriptCore

[Eric Seidel]

I've posted my first-draft patch to:
https://bugs.webkit.org/show_bug.cgi?id=81844

If port maintainers would like to apply it locally and upload improved
versions (or upload diffs on top of that version) that would be most
welcome.


svn-apply seems to be having trouble with the "adds" for the WTF
files, thus causing all the EWS bots to fail.

I'm also working on getting a git branch (on github) of my changes, to
make it easier for port maintainers to send me updates (instead of
passing around 5MB diffs).


At this point it may be best to just land the change tomorrow and fix
all the buildbots after the fact.  We should be very close, with all
the header work which has been done over the last month.

-eric

On Tue, Mar 20, 2012 at 5:18 PM, Eric Seidel  wrote:
> We're ready to complete the move.
>
> https://bugs.webkit.org/show_bug.cgi?id=80911 should land later this
> evening, moving JavaScriptCore/wtf/Platform.h to Source/WTF/Platform.h
>
> Tomorrow (Weds) I will move a .cpp file in the same way.
>
> Thursday, I will move all the rest of the WTF files.  I will also
> update svn-apply so that in-flight patches should transparently patch
> the right files post-move.
>
> Let me know if you have questions or concerns.
>
> -eric
>
> On Tue, Feb 28, 2012 at 3:53 PM, Eric Seidel  wrote:
>> I'm going to push off the move, probably until next week.
>>
>> Thank you for the Qt patch!
>>
>> I'll post a patch for Mark and we can discuss further from there.
>>
>> -eric
>>
>> On Tue, Feb 28, 2012 at 7:38 AM, Osztrogonac Csaba  
>> wrote:
>>> Hi,
>>>
>>> I uploaded the necessary buildfix for Qt to the bugzilla:
>>> https://bugs.webkit.org/show_bug.cgi?id=79783 .
>>>
>>> Please be careful with moving JavaScriptCore/wtf to WTF, because we
>>> need zillion trivial fixes for case sensitive file systems. (~4000 files!!!)
>>>
>>> I made it locally to be able prepare the Qt buildfix and I had to replace
>>> all
>>> "wtf" to "WTF includes everywhere. (*.cpp, *.h, *.y, *.py, *.pl, *.pm, ...)
>>> The patch is huge, ~2Mb and ~4000 files are affected.
>>>
>>> I suggest landing the following patches separately:
>>> - Moving Sources/JavaScriptCore/wtf --> Sources/WTF
>>> - s/wtf/WTF/g patch :)
>>> - platform buildfixes
>>>
>>> Please let me know if you have the new date for landing these patches. I
>>> would be happier with a more CET timezone friendly timing. - 08:00-00:00 in
>>> CET.
>>>
>>> br,
>>> Ossy
>>>
>>> Eric Seidel írta:
>>>
 We've been talking about moving WTF out of JavaScriptCore for a long
 time.  We believe we're nearly there.
 https://bugs.webkit.org/show_bug.cgi?id=75673

 This will mean that WTF will be built as a separate static library on all
 ports.

 The plan is to do this move all in one piece, after work hours PST,
 when the tree is least active.

 It won't be the most beautiful transition (as we're likely to break at
 least one port in the process), but we'll try not to make too much of
 a mess.

 We believe all the ports are ready for the move, except AppleWin:
 https://bugs.webkit.org/show_bug.cgi?id=75897

 Once AppleWin is ready we'll schedule a date for the transition and
 announce it one this thread.

 Thanks!

 -eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Documentation for WTF/JSC exports?

[Eric Seidel]

Thank you.  Mark Rowe was kind enough to resolve
https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in
http://trac.webkit.org/changeset/111634.

I've found that some of the "Weak External Symbol" errors from
http://pastebin.com/dVjV8UiR can be resolved by marking the functions
in question as "inline", but that doesn't seem like the right fix.

Some others like:
ERROR: symbol double WTF::strtod<(WTF::AllowTrailingJunkTag)0,
(WTF::AllowTrailingSpacesTag)0>(char const*, char**)

Are for functions which are not even in headers:
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651

So it's unclear what's causing those.

Thank you for your attempts at documentation. Perhaps that will make
clear how these exports are supposed to work. :)

-eric

On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita  wrote:
> I'll write a draft so that ports' expert can fill missing pieces.
> --
> morrita
>
> On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel  wrote:
>> Do we have any documentation for how the current symbol export system
>> for WTF/JSC is supposed to work?
>>
>> I'm hitting errors when trying to move WTF files to their own libwtf.a, such 
>> as:
>> https://bugs.webkit.org/show_bug.cgi?id=81838
>> and
>> http://pastebin.com/dVjV8UiR
>>
>> But looking at 
>> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h
>>
>> It appears most of those macros are never used!  (Like
>> WTF_EXPORT_CLASS, for example.)
>>
>> So when trying to resolve errors such as:
>> https://bugs.webkit.org/show_bug.cgi?id=81838#c8
>>
>> The path is unclear.
>>
>> Perhaps there is a wiki somewhere on how this system is supposed to work?
>>
>> -eric
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> --
> morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Documentation for WTF/JSC exports?

[Hajime Morrita]

I'll write a draft so that ports' expert can fill missing pieces.
--
morrita

On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel  wrote:
> Do we have any documentation for how the current symbol export system
> for WTF/JSC is supposed to work?
>
> I'm hitting errors when trying to move WTF files to their own libwtf.a, such 
> as:
> https://bugs.webkit.org/show_bug.cgi?id=81838
> and
> http://pastebin.com/dVjV8UiR
>
> But looking at 
> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h
>
> It appears most of those macros are never used!  (Like
> WTF_EXPORT_CLASS, for example.)
>
> So when trying to resolve errors such as:
> https://bugs.webkit.org/show_bug.cgi?id=81838#c8
>
> The path is unclear.
>
> Perhaps there is a wiki somewhere on how this system is supposed to work?
>
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Documentation for WTF/JSC exports?

[Eric Seidel]

Do we have any documentation for how the current symbol export system
for WTF/JSC is supposed to work?

I'm hitting errors when trying to move WTF files to their own libwtf.a, such as:
https://bugs.webkit.org/show_bug.cgi?id=81838
and
http://pastebin.com/dVjV8UiR

But looking at 
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h

It appears most of those macros are never used!  (Like
WTF_EXPORT_CLASS, for example.)

So when trying to resolve errors such as:
https://bugs.webkit.org/show_bug.cgi?id=81838#c8

The path is unclear.

Perhaps there is a wiki somewhere on how this system is supposed to work?

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Dirk Pranke]

On Wed, Mar 21, 2012 at 4:18 PM, Timothy Hatcher  wrote:
>
> On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:
>
> I think this is a reasonable suggestion, but I don't agree with it :).
> I would prefer that we try to get good changelogs through culture and
> convention rather than through good tooling.
>
> This is of course based on my experience in my changes and the types
> of changes I review, but I personally find what value there is at all
> in ChangeLogs in the paragraphs at the top of the change, and I find
> the lists of changed files and to be distracting noise far more often
> than not. (Perhaps things are different in changes to the core
> rendering code than changes to tooling and test code).
>
>
> I find the comments useful, even for scripts. ChangeLogs for tests are often
> more mundane.
>

I should clarify that I do find value in describing the why of the
change, so I could agree w/ Maciej that requiring *something* more
than the subject + bug + reviewer might be justified for changes. Just
linking to a bug would be overly terse.

My annoyance with ChangeLogs stems from just integrating them into my
workflow (which often involves multiple pipelined changes and/or lots
of merging and rebasing), but that's off-topic for this thread. I am
also sometimes annoyed by ChangeLogs when a change happens to span
multiple ChangeLogs and I either have to repeat myself or figure out
how to split my description between the files, which is slightly more
on-topic.

Mostly I just don't want there to be a lot of boilerplate or noise in
the ChangeLogs.

-- Dirk

> My particular interest is the Web Inspector, which I follow by watching bugs
> and commits. Often I find myself asking "why?" or "what does this do?" when
> perusing the commits. It sometimes isn't very obvious and a nice concise
> description in the ChangeLog would help. This is even more important when
> folks are separated by timezones or are not easy to reach for explanation.
>
> They also provide insight when looking back on changes from months or years
> ago when tracking down a regression.
>
> I think it is difficult to say what a "good" changelog is an any sort
> of algorithmic sense, and trying to implement something that would be
> done programmatically will be more annoying than useful (even if it
> means that I just have to delete a bunch of "OOPS" lines).
>
>
> It would be difficult to make the tool smart. I merely looking for reminder
> to push folks to describe their changes in some fashion, not a analytical
> tool parsing for good vs bad.
>
> — Timothy Hatcher
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Timothy Hatcher]

On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:

> I think this is a reasonable suggestion, but I don't agree with it :).
> I would prefer that we try to get good changelogs through culture and
> convention rather than through good tooling.
> 
> This is of course based on my experience in my changes and the types
> of changes I review, but I personally find what value there is at all
> in ChangeLogs in the paragraphs at the top of the change, and I find
> the lists of changed files and to be distracting noise far more often
> than not. (Perhaps things are different in changes to the core
> rendering code than changes to tooling and test code).

I find the comments useful, even for scripts. ChangeLogs for tests are often 
more mundane.

My particular interest is the Web Inspector, which I follow by watching bugs 
and commits. Often I find myself asking "why?" or "what does this do?" when 
perusing the commits. It sometimes isn't very obvious and a nice concise 
description in the ChangeLog would help. This is even more important when folks 
are separated by timezones or are not easy to reach for explanation.

They also provide insight when looking back on changes from months or years ago 
when tracking down a regression.

> I think it is difficult to say what a "good" changelog is an any sort
> of algorithmic sense, and trying to implement something that would be
> done programmatically will be more annoying than useful (even if it
> means that I just have to delete a bunch of "OOPS" lines).


It would be difficult to make the tool smart. I merely looking for reminder to 
push folks to describe their changes in some fashion, not a analytical tool 
parsing for good vs bad.

— Timothy Hatcher

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

Re: [webkit-dev] ChangeLogs

[Maciej Stachowiak]

On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:

> On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak  wrote:
>> 
>> On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
>> 
>> Lately I have observed more and more and more changes going into WebKit that
>> lack any details about why a particular change was made. It is intended that
>> the ChangeLog (and commit message) contain some details about your change,
>> not just the bug title and URL.
>> 
>> The contributing information on subject is pretty sparse, which has likely
>> caused this problem to manifest. However, the example ChangeLog linked from
>> that page is prime example of what we all should strive for when describing
>> our changes.
>> 
>> To help curb this lack of detail in ChangeLogs, I propose we add script (or
>> augment an existing script) to check for this missing information and inform
>> the contributor. It is clear not all reviewers are asking patch authors to
>> provide this information when reviewing, and such a tool would help enforce
>> it.
>> 
>> 
>> I think this is a reasonable suggestion. I think we should make the
>> contributor docs more clear about what is expected, as well.
>> 
> 
> I think this is a reasonable suggestion, but I don't agree with it :).
> I would prefer that we try to get good changelogs through culture and
> convention rather than through good tooling.
> 
> This is of course based on my experience in my changes and the types
> of changes I review, but I personally find what value there is at all
> in ChangeLogs in the paragraphs at the top of the change, and I find
> the lists of changed files and to be distracting noise far more often
> than not. (Perhaps things are different in changes to the core
> rendering code than changes to tooling and test code).

I agree that setting the right conventions, and getting agreement on this, is 
the most important step. I think the ChangeLogs that are most worrisome are the 
ones that do not even have an explanatory paragraph at the top, just a bug URL 
and title. It can be hard to understand the 

I often really appreciate ChangeLogs with file-by-file or even 
function-by-function explanations, but I wouldn't say that is the bare minimum 
required for all changes. For simple changes, a short paragraph above may be 
totally sufficient. It is very rare that just the bug URL and title are 
sufficient, though.

Regards,
Maciej



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

Re: [webkit-dev] ChangeLogs

[Adam Barth]

On Wed, Mar 21, 2012 at 3:45 PM, Timothy Hatcher  wrote:
> On Mar 21, 2012, at 2:46 PM, Adam Barth wrote:
>> On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher  wrote:
>>> Lately I have observed more and more and more changes going into WebKit that
>>> lack any details about why a particular change was made. It is intended that
>>> the ChangeLog (and commit message) contain some details about your change,
>>> not just the bug title and URL.
>>
>> Since I was the reviewer for 
>> (although if you look in the bug thread, you'll see that I was just
>> forwarding fishd's R+ after some trivial cleanups), I'm curious what
>> additional information you think should have been included in that
>> ChangeLog.
>>
>> There really isn't much to say about that change.  Tommy was just
>> adding thin API wrappers around WebCore objects as part of the
>> implementation of the MediaStream API.  The main point of discussion
>> in the bug thread was whether to use the name ICE or Ice.
>
> "Adding thin API wrappers around WebCore objects as part of the 
> implementation of the MediaStream API." would be a good start. I shouldn't 
> have to troll through a bug with 21 comments to figure out a change. Also the 
> WebCore changes are just case changes, but you wouldn't know that by just 
> perusing the ChangeLog/commit message.

Yeah, I definitely find ChangeLog messages useful for filtering which
changes to dig into in more detail (e.g., when hunting for a
regression).  Thanks!

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Timothy Hatcher]

On Mar 21, 2012, at 2:46 PM, Adam Barth wrote:

> On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher  wrote:
>> Lately I have observed more and more and more changes going into WebKit that
>> lack any details about why a particular change was made. It is intended that
>> the ChangeLog (and commit message) contain some details about your change,
>> not just the bug title and URL.
> 
> Since I was the reviewer for 
> (although if you look in the bug thread, you'll see that I was just
> forwarding fishd's R+ after some trivial cleanups), I'm curious what
> additional information you think should have been included in that
> ChangeLog.
> 
> There really isn't much to say about that change.  Tommy was just
> adding thin API wrappers around WebCore objects as part of the
> implementation of the MediaStream API.  The main point of discussion
> in the bug thread was whether to use the name ICE or Ice.
> 
> Adam


"Adding thin API wrappers around WebCore objects as part of the implementation 
of the MediaStream API." would be a good start. I shouldn't have to troll 
through a bug with 21 comments to figure out a change. Also the WebCore changes 
are just case changes, but you wouldn't know that by just perusing the 
ChangeLog/commit message.

— Timothy Hatcher


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

Re: [webkit-dev] ChangeLogs

[Dirk Pranke]

On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak  wrote:
>
> On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
>
> Lately I have observed more and more and more changes going into WebKit that
> lack any details about why a particular change was made. It is intended that
> the ChangeLog (and commit message) contain some details about your change,
> not just the bug title and URL.
>
> The contributing information on subject is pretty sparse, which has likely
> caused this problem to manifest. However, the example ChangeLog linked from
> that page is prime example of what we all should strive for when describing
> our changes.
>
> To help curb this lack of detail in ChangeLogs, I propose we add script (or
> augment an existing script) to check for this missing information and inform
> the contributor. It is clear not all reviewers are asking patch authors to
> provide this information when reviewing, and such a tool would help enforce
> it.
>
>
> I think this is a reasonable suggestion. I think we should make the
> contributor docs more clear about what is expected, as well.
>

I think this is a reasonable suggestion, but I don't agree with it :).
I would prefer that we try to get good changelogs through culture and
convention rather than through good tooling.

This is of course based on my experience in my changes and the types
of changes I review, but I personally find what value there is at all
in ChangeLogs in the paragraphs at the top of the change, and I find
the lists of changed files and to be distracting noise far more often
than not. (Perhaps things are different in changes to the core
rendering code than changes to tooling and test code).

I think it is difficult to say what a "good" changelog is an any sort
of algorithmic sense, and trying to implement something that would be
done programmatically will be more annoying than useful (even if it
means that I just have to delete a bunch of "OOPS" lines).

-- Dirk

> Regards,
> Maciej
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Ryosuke Niwa]

On Wed, Mar 21, 2012 at 2:41 PM, David Levin  wrote:

> I think the challenge in part is to explain why the ChangeLog is useful.
>
> Comments in there hopefully explain why as a guide to reviewers to give
> the reviewers and future onlookers a guide to the change.
>

I do agree that "why" comments are more useful than "what" comments are
most cases.

However, I'd say it's also helpful to summarize what a new function / class
does as well if the patch adds one. Since comments in the change log is for
a specific revision unlike comments in the code, it's less dangerous to add
"what" comment.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] 2012 WebKit Contributors' meeting

[Ryosuke Niwa]

FYI, there's a wiki page to add potential topics and hackathon ideas for
the meeting: http://trac.webkit.org/wiki/April%202012%20Meeting

On Tue, Mar 20, 2012 at 4:22 PM, Sam Weinig  wrote:

> Apple will once again be hosting a WebKit Contributors Meeting. It will be
> held at the Cypress Hotel in Cupertino, CA on April 19 and 20. This meeting
> is for contributors to the WebKit Open Source Project. As with the meeting
> last year, this event will have an "unconference"-like format, allowing
> plenty of time for impromptu sessions/discussions and hacking.
>
> The meeting will be free of charge. All WebKit contributors are encouraged
> to attend. However, space is limited, so registrations will be accepted on
> a first-come, first-served basis.
>
> Please register for the conference using the form at
> https://www.webkit.org/meeting/ by April 11. When you register, you will
> automatically be subscribed to webkit-meet...@lists.webkit.org, which
> will be used for general discussion and to communicate additional
> information about the meeting.
>
> If you have any questions about the meeting, or about whether this meeting
> is appropriate for you to attend, you may email me at wei...@apple.com.
>
> We hope to see you there!
>
> Thanks,
> Sam Weinig
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Adam Barth]

On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher  wrote:
> Lately I have observed more and more and more changes going into WebKit that
> lack any details about why a particular change was made. It is intended that
> the ChangeLog (and commit message) contain some details about your change,
> not just the bug title and URL.

Since I was the reviewer for 
(although if you look in the bug thread, you'll see that I was just
forwarding fishd's R+ after some trivial cleanups), I'm curious what
additional information you think should have been included in that
ChangeLog.

There really isn't much to say about that change.  Tommy was just
adding thin API wrappers around WebCore objects as part of the
implementation of the MediaStream API.  The main point of discussion
in the bug thread was whether to use the name ICE or Ice.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[David Levin]

I think the challenge in part is to explain why the ChangeLog is useful.

Comments in there hopefully explain why as a guide to reviewers to give the
reviewers and future onlookers a guide to the change.

It feels like what comments are that useful but often get inserted in there
to fill it out. Is there a good way to address this? (Should folks just
leave what comments out or put in the obvious what?)

Since we have an example ChangeLog, I'll point out what I mean using it
(but it is evident in many ChangeLog's from me as well).

What value does this comment add?

   - runtime/JSGlobalData.h: Replaced the HashSet and HashCountedSet with a
   Vector.

On the other hand, I found this very informative:

wtf/PassRefPtr.h:
(WTF::PassRefPtr::~PassRefPtr): The most common thing to do with a
PassRefPtr in hot code is to pass it and then destroy it once it's
set to zero. Help the optimizer by telling it that's true.




Here again, we see a what comment:

parser/Nodes.cpp:
(JSC::NodeReleaser::releaseAllNodes): ALWAYS_INLINE.
(JSC::NodeReleaser::adopt): Ditto.

Which doesn't tell me why ALWAYS_INLINE was added (which I can easily see
from the patch).

dave

On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak  wrote:

>
> On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
>
> Lately I have observed more  and
> more  and 
> more changes
> going into WebKit that lack any details about why a particular change was
> made. It is intended that the ChangeLog (and commit message) contain some
> details about your change, not just the bug title and URL.
>
> The contributing 
> information on
> subject is pretty sparse, which has likely caused this problem to manifest.
> However, the example ChangeLog  linked
> from that page is prime example of what we all should strive for when
> describing our changes.
>
> To help curb this lack of detail in ChangeLogs, I propose we add 
> script (or
> augment an existing script) to check for this missing information and
> inform the contributor. It is clear not all reviewers are asking patch
> authors to provide this information when reviewing, and such a tool would
> help enforce it.
>
>
> I think this is a reasonable suggestion. I think we should make the
> contributor docs more clear about what is expected, as well.
>
> Regards,
> Maciej
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Konrad Piascik]

There are some changes which have bug descriptions which are complete enough to 
not need additional comments and any changes to existing scripts should keep 
this in mind. One way to do this is to check for the number of lines/files the 
diff has.
Konrad
Sent from my BlackBerry on the Rogers Wireless Network

From: Timothy Hatcher [mailto:timo...@apple.com]
Sent: Wednesday, March 21, 2012 05:29 PM
To: webkit-dev@lists.webkit.org 
Subject: [webkit-dev] ChangeLogs

Lately I have observed more and 
more and 
more changes going into WebKit that 
lack any details about why a particular change was made. It is intended that 
the ChangeLog (and commit message) contain some details about your change, not 
just the bug title and URL.

The contributing 
information on 
subject is pretty sparse, which has likely caused this problem to manifest. 
However, the example ChangeLog linked 
from that page is prime example of what we all should strive for when 
describing our changes.

To help curb this lack of detail in ChangeLogs, I propose we add 
script (or augment an existing 
script) to check for this missing information and inform the contributor. It is 
clear not all reviewers are asking patch authors to provide this information 
when reviewing, and such a tool would help enforce it.

— Timothy Hatcher


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLogs

[Maciej Stachowiak]

On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:

> Lately I have observed more and more and more changes going into WebKit that 
> lack any details about why a particular change was made. It is intended that 
> the ChangeLog (and commit message) contain some details about your change, 
> not just the bug title and URL.
> 
> The contributing information on subject is pretty sparse, which has likely 
> caused this problem to manifest. However, the example ChangeLog linked from 
> that page is prime example of what we all should strive for when describing 
> our changes.
> 
> To help curb this lack of detail in ChangeLogs, I propose we add script (or 
> augment an existing script) to check for this missing information and inform 
> the contributor. It is clear not all reviewers are asking patch authors to 
> provide this information when reviewing, and such a tool would help enforce 
> it.

I think this is a reasonable suggestion. I think we should make the contributor 
docs more clear about what is expected, as well.

Regards,
Maciej


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

[webkit-dev] ChangeLogs

[Timothy Hatcher]

Lately I have observed more and more and more changes going into WebKit that 
lack any details about why a particular change was made. It is intended that 
the ChangeLog (and commit message) contain some details about your change, not 
just the bug title and URL.

The contributing information on subject is pretty sparse, which has likely 
caused this problem to manifest. However, the example ChangeLog linked from 
that page is prime example of what we all should strive for when describing our 
changes.

To help curb this lack of detail in ChangeLogs, I propose we add script (or 
augment an existing script) to check for this missing information and inform 
the contributor. It is clear not all reviewers are asking patch authors to 
provide this information when reviewing, and such a tool would help enforce it.

— Timothy Hatcher

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

Re: [webkit-dev] Anyone using NEON code on ARM builds?

[Zoltan Herczeg]

Hi,

btw if anyone interested about the details of this optimization you can
read more about it here:

http://blogs.arm.com/software-enablement/699-using-arm-neon-to-accelerate-scalable-vector-graphics-in-webkit-by-up-to-4X/

Regards,
Zoltan

> Hi Jonathan,
>
> On 21/03/2012, at 12:56 AM, Jonathan Kliegman wrote:
>
>> On Wed, Mar 14, 2012 at 2:14 PM, Dean Jackson  wrote:
>> Hi,
>>
>> There are three files with embedded NEON code to speed up filters:
>>
>> ./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
>> ./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
>> ./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}
>>
>> Are any ARM ports using this? (would require SVG and FILTERS both
>> enabled) If so, could you contact me? Off list is fine.
>>
>> I see the code came from Felician Marton via Zoltan reviewed by Dirk
>> (eg. https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very
>> slightly touched for some chromium build issues.
>>
>> Chrome OS has ports that use NEON and has SVG and FILTERS both enabled
>> so this would still be used.
>
> Excellent!
>
> Zoltan and I have been chatting offline a bit. I was testing compilation
> on Darwin/iOS ARM and running into a few issues. The first was about
> alignment errors from the compiler. The second was some linking issues,
> for example:
>
>> https://bugs.webkit.org/show_bug.cgi?id=81568
>
> Is there someone (you?) on the Chrome team I should CC on any bugs raises?
>
> Dean
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>


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