Re: [webkit-dev] Nicks in contributors.json

2022-10-25 Thread Fujii Hironori via webkit-dev
On Tue, Oct 25, 2022 at 4:11 PM Anne van Kesteren via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> We currently do not surface email addresses on the website, but we
> could. Would it make sense to surface just the first email address
> listed?
>

We don't use email addresses usually through WebKit development.
I don't like the idea of exposing email addresses on the web.
There are a lot of inactive members in contributors.json. We can't make a
consensus to do it.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] CMake EWS now use -Werror

2022-10-25 Thread Michael Catanzaro via webkit-dev

Hi developers,

The Apple EWS bots have long used -Werror to make warnings fatal, 
discouraging inadvertently introducing new build warnings. But CMake 
EWS bots did not, until now. The new CMake behavior after 
https://commits.webkit.org/255961@main is:


* By default, warnings are not fatal.
* Warnings become fatal if you use the -DDEVELOPER_MODE=ON CMake flag. 
The build-webkit script always enables this.
* An off switch exists, -DDEVELOPER_MODE_FATAL_WARNINGS=OFF, with a 
corresponding --no-fatal-warnings flag for build-webkit. Use this 
whenever you're bisecting, or when you're in a hurry and don't have 
time to deal with particular warnings.
* All post-commit bots now build with --no-fatal-warnings to avoid 
losing test results to a compiler warning. The EWS does not, to 
discourage introduction of new warnings.


Some common warnings to avoid:

* -Wreturn-type is by far the most common GCC warning introduced into 
WebKit. This occurs when you expect a switch statement to always 
return, but forget to ensure that it really does when passed an invalid 
enum value. Clang does not complain about these, so only the bots using 
GCC will notice it. The normal solution is to add 
RELEASE_ASSERT_NOT_REACHED() to the bottom of the function. In 
especially hot functions,  that might have performance impact, and you 
might need to write the code in an alternative way or use 
IGNORE_RETURN_TYPE_WARNINGS_BEGIN/END from Compiler.h. (I've considered 
disabling this warning due to how frequently we introduce code that 
trips it, but have left it because returning bogus data is very bad.)
* -Wunused-parameter and -Wunused-variable warnings often occur around 
ENABLE() or USE() build guards. Use UNUSED_PARAM() and 
UNUSED_VARIABLE(), respectively, to suppress these. Note that 
Source/WebKit builds with -Wno-unused-parameter, but most of the rest 
of WebKit does not.
* -Wredundant-move occurs when you write "return WTFMove(foo)" and the 
solution is to remove the WTFMove(). Clang only warns when the move 
blocks return value optimization, but GCC warns always.


Of course there are plenty more warnings you might encounter, but those 
are the most common ones. If you find something you don't know how to 
deal with, don't hesitate to ask for help. False positives can be 
suppressed using IGNORE_WARNINGS_BEGIN() and IGNORE_WARNINGS_END() or 
one of the similar macros from Compiler.h.


I believe the --no-fatal-warnings flag is not currently hooked up to 
anything on Apple ports. This would be good to improve.


Michael


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


[webkit-dev] New `request-merge-queue` label

2022-10-25 Thread Jonathan Bedard via webkit-dev
Hey folks,

There was a request to add an equivalent to Bugzilla's “cq?” in GitHub. This 
morning, I added the `request-merge-queue` label, 
https://github.com/WebKit/WebKit/labels?q=request-merge-queue. Since GitHub 
lets you filter PRs on labels 
(https://github.com/WebKit/WebKit/pulls?q=is%3Apr+is%3Aopen+label%3Arequest-merge-queue),
 this should allow non-committers to request committers to apply the 
`merge-queue` label.

Jonathan
WebKit Continuous Integration___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Nicks in contributors.json

2022-10-25 Thread Anne van Kesteren via webkit-dev
On Mon, Oct 24, 2022 at 11:07 PM Darin Adler  wrote:
> If they were consistently the Slack nicknames. But they often aren’t! The 
> nicknames currently in there don’t necessarily match the Slack ones and 
> obviously don’t match the GitHub account names. I wish these were more 
> explicit about what they are! I had no idea that they were the ones still 
> used in bugs.webkit.org. I would love to see the list of what name each 
> person used on what service, email, bugs.webkit.org, Slack, and GitHub, if 
> there was some economical way of doing it.

Presumably bugs.webkit.org is going the way of the dodo so that should
solve itself. Not sure what the timeline for that will be, but we can
wait with removing nicks until that happens.

For Slack we could have a dedicated slack field to capture the user ID
which would allow us to create a variety of "deep" links (e.g., to the
user's profile or to direct message the user).

We currently do not surface email addresses on the website, but we
could. Would it make sense to surface just the first email address
listed? (As with GitHub I would use an icon here so it shouldn't take
up a lot of space.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev