[webkit-dev] Recommended GitHub Settings

2021-10-21 Thread Jonathan Bedard via webkit-dev
Hey folks,

We’ve had some contributors reach out to us about notifications they are 
starting to receive because of our development of GitHub pull-requests. Given 
the size of the WebKit project, we have a few recommendations of how to 
configure your notification settings. On https://github.com/WebKit/WebKit 
, under the “Watch” menu, you can pick when 
you are notified. By default, this is “All Activity,” which will include every 
pull-request anyone makes. It’s unlikely this is desirable. You most likely 
want to only be notified on pull-requests you are specifically mentioned in or 
are participating in, if you want to be notified at all.

In addition to this, I will start inviting active contributors to the WebKit 
organization based on the GitHub usernames in contributors.json. You should be 
able to accept this invite at https://github.com/WebKit 
 when it comes.

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


[webkit-dev] GitHub Usernames in contributors.json

2021-10-08 Thread Jonathan Bedard via webkit-dev
Hello WebKittens,

As I continue to bring up GitHub infrastructure, it’s coming time to start 
representing various permissions of the WebKit project in GitHub. In order to 
represent these permissions, we need a record of active contributor’s GitHub 
usernames. We’re doing this in contributors.json, which has now been moved to 
metadata/contributors.json.

Adding GitHub users is supported as of 242713@main 
 (r283833 
).

The expectation is that active contributors are adding their usernames to 
contributors.json over the next 4-6 weeks. A GitHub username in 
contributors.json will be necessary to retain committer and reviewer privileges 
as we transition to GitHub.

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


Re: [webkit-dev] Identifiers in Log and Blame

2021-08-17 Thread Jonathan Bedard via webkit-dev
GitHub has a native blame viewer, 
https://github.com/WebKit/WebKit/blame/main/Makefile 
<https://github.com/WebKit/WebKit/blame/main/Makefile>, which doesn’t display 
any commit string, but seems to display significantly more useful information 
than what the equivalent trac view is 
https://trac.webkit.org/browser/webkit/trunk/Makefile?annotate=blame=281147 
<https://trac.webkit.org/browser/webkit/trunk/Makefile?annotate=blame=281147>.
 Given that Trac’s view makes it difficult to copy revision numbers and would 
instead tend to route a user towards following a link to the blamed commit, 
just like GitHub, I don’t think trying to integrate this solution to GitHub’s 
blame UI makes sense.  Also, the technical challenges of doing so are likely to 
be considerable.

Jonathan

> On Aug 17, 2021, at 11:18 AM, Ryosuke Niwa  wrote:
> 
> Seems like a good improvement but I really don't use command line tools to 
> see my blame. What I need is this getting applied to a online tools like trac 
> and GitHub.
> 
> On Tue, Aug 17, 2021 at 10:57 AM Jonathan Bedard via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
> Hi folks,
> 
> As we move towards using Git as our version control system, more services and 
> scripts will be using identifiers instead of revisions or hashes.  Already, 
> build.webkit.org <http://build.webkit.org/>, results.webkit.org 
> <http://results.webkit.org/> and ews-build.webkit.org 
> <http://results.webkit.org/> all display identifiers alongside revisions.  
> Early in the transition process, we added the git-webkit find command, which 
> converts between hashes, revisions and identifiers.  Recently, we added the 
> git-webkit log and git-webkit blame commands to better support identifiers 
> and native Git checkouts.
> 
> git-webkit log is a wrapper around git log or svn log (depending on your 
> checkout) and annotates the output of those commands with identifiers and 
> revisions. git-webkit log passes the arguments you provide it to your native 
> source code management system, it’s output looks something like this:
> 
> commit 240602@main (fe5476762fc34d2a5547b7d2d8116faa7275acd7, r281148)
> Author: Eric Hutchison mailto:ehutchi...@apple.com>>
> Date:   Tue Aug 17 17:46:39 2021 +
> 
> [Monterey wk2 Release] 
> performance-api/paint-timing/paint-timing-with-worker.html is a flaky crash.
> rdar://82036119 <>.
> ...
> 
> git-webkit blame is a wrapper around git blame or svn blame (again, depending 
> on your checkout) and also annotates the output of these commands with 
> identifiers:
> 
> 230258@main (Keith Rollin2020-10-08 19:10:32 +  1) MODULES = Source 
> Tools
> 184786@main (Jonathan Bedard 2017-02-02 18:42:02 +  2) 
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  3) define 
> build_target_for_each_module
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  4)  for dir in 
> $(MODULES); do \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  5)  
> ${MAKE} $@ -C $$dir PATH_FROM_ROOT=$(PATH_FROM_ROOT)/$${dir}; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  6)  
> exit_status=$$?; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  7)  [ 
> $$exit_status -ne 0 ] && exit $$exit_status; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  8)  done; true
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  9) endef
> ...
> 
> Both commands can switch the commit representation they display with the 
> --identifier, --hash and --revision options.
> 
> Additionally, for those using Git checkouts, the conversion from Subversion 
> revisions to Git hashes no longer requires your checkout to be configured 
> with git-svn. Contributors may find that something like git checkout r281146 
> satisfies whatever need they have to interact with Subversion from Git.
> 
> All of this has been landed on trunk/main as of r280864/240404@main.
> 
> Jonathan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>

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


[webkit-dev] Identifiers in Log and Blame

2021-08-17 Thread Jonathan Bedard via webkit-dev
Hi folks,

As we move towards using Git as our version control system, more services and 
scripts will be using identifiers instead of revisions or hashes.  Already, 
build.webkit.org , results.webkit.org 
 and ews-build.webkit.org 
 all display identifiers alongside revisions.  
Early in the transition process, we added the git-webkit find command, which 
converts between hashes, revisions and identifiers.  Recently, we added the 
git-webkit log and git-webkit blame commands to better support identifiers and 
native Git checkouts.

git-webkit log is a wrapper around git log or svn log (depending on your 
checkout) and annotates the output of those commands with identifiers and 
revisions. git-webkit log passes the arguments you provide it to your native 
source code management system, it’s output looks something like this:

commit 240602@main (fe5476762fc34d2a5547b7d2d8116faa7275acd7, r281148)
Author: Eric Hutchison 
Date:   Tue Aug 17 17:46:39 2021 +

[Monterey wk2 Release] 
performance-api/paint-timing/paint-timing-with-worker.html is a flaky crash.
rdar://82036119.
...

git-webkit blame is a wrapper around git blame or svn blame (again, depending 
on your checkout) and also annotates the output of these commands with 
identifiers:

230258@main (Keith Rollin2020-10-08 19:10:32 +  1) MODULES = Source 
Tools
184786@main (Jonathan Bedard 2017-02-02 18:42:02 +  2) 
229628@main (Keith Rollin2020-09-22 18:37:51 +  3) define 
build_target_for_each_module
229628@main (Keith Rollin2020-09-22 18:37:51 +  4)  for dir in 
$(MODULES); do \
229628@main (Keith Rollin2020-09-22 18:37:51 +  5)  ${MAKE} 
$@ -C $$dir PATH_FROM_ROOT=$(PATH_FROM_ROOT)/$${dir}; \
229628@main (Keith Rollin2020-09-22 18:37:51 +  6)  
exit_status=$$?; \
229628@main (Keith Rollin2020-09-22 18:37:51 +  7)  [ 
$$exit_status -ne 0 ] && exit $$exit_status; \
229628@main (Keith Rollin2020-09-22 18:37:51 +  8)  done; true
229628@main (Keith Rollin2020-09-22 18:37:51 +  9) endef
...

Both commands can switch the commit representation they display with the 
--identifier, --hash and --revision options.

Additionally, for those using Git checkouts, the conversion from Subversion 
revisions to Git hashes no longer requires your checkout to be configured with 
git-svn. Contributors may find that something like git checkout r281146 
satisfies whatever need they have to interact with Subversion from Git.

All of this has been landed on trunk/main as of r280864/240404@main.

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


[webkit-dev] Fixed merged commits in GitHub Mirror

2021-07-28 Thread Jonathan Bedard via webkit-dev
Morning folks,

Last Friday, git-svn failed us and merged two commits together (this was the 
cause of the incorrect commits.webkit.org  links 
folks saw over the last few days). I’ve fixed it, but that fix involves 
force-pushing, if you have a GitHub checkout, you might need to `git reset 
HEAD~125 —hard` and re-pull to fix the problem (be aware of local commits you 
may have, because `git reset —hard` will throw those out).

Thank you for your patience,

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


[webkit-dev] Identifier Conversion Tooling

2021-02-12 Thread Jonathan Bedard via webkit-dev
Hello contributors,

As we move forward with the transition to GitHub, we are starting to adopt 
identifiers  in tooling and 
infrastructure. This is going to take a few weeks, but you will start seeing 
links based on identifiers more frequently. During this transition period, not 
all tooling will work with identifiers, and it’s possible there are tools you 
rely on that aren’t in common use so will be slow in receiving support. To that 
end, I would like to share the tools available to translate between hashes, 
revisions and identifiers in WebKit, along with the Python libraries backing 
that tooling if you feel motivated to expedite the transition for a workflow 
that is particularly important to you.

Tools/Scripts/git-webkit find  is the local script that can convert 
between revisions, hashes and identifiers. By default, it uses your local 
checkout, which means it may be restricted by your checkout’s configuration. 
For example, a pure Subversion checkout will be unable to convert hashes and a 
pure Git checkout will be unable to convert revisions, while a Git-Svn checkout 
will be able to translate all three formats.

If you want to be certain that a hash or revision can be converted to an 
identifier, running Tools/Scripts/git-webkit -C 
https://svn.webkit.org/repository/webkit 
 find  or 
Tools/Scripts/git-webkit -C https://github.com/WebKit/Webkit 
 find  are options. These command 
operate entirely on the network, instead of relying on your local checkout.

Both variations of git-webkit find are ultimately thin wrappers around 
webkitscmpy local.Scm and remote.Scm classes, so if you find yourself working 
with Python code, consider leveraging the APIs directly.

Lastly, along with redirecting to trac/GitHub, the site 
https://commits.webkit.org  has a JSON API which 
vends a representation of a commit which includes the hash, revision and 
identifier and looks like this: https://commits.webkit.org/234036@main/json 
. commits.webkit.org 
 is a service we are dedicated to maintaining 
permanently, since it allows us to vend commit links with identifiers instead 
of hashes.

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


[webkit-dev] Scripts default to Python 3

2021-02-04 Thread Jonathan Bedard via webkit-dev
Hello contributors,

Now that trunk no longer supports Mojave, it’s time to change our Python 
shebangs to Python 3 in our scripts. 
https://bugs.webkit.org/show_bug.cgi?id=221411 
 is the umbrella bug that 
covers this change. We aren’t ready to drop Python 2 support quite yet, among 
other reasons, there is still some work to be done for run-webkit-tests and 
run-api-tests to support Python 3.8, but this is one step closer to that goal.

Jonathan
WebKit Continuous Integration

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


Re: [webkit-dev] Replacing PHP with Python in Layout Tests

2021-02-02 Thread Jonathan Bedard via webkit-dev

>> Hello Contributors,
>> 
>> To help reduce the number of dependencies WebKit?s tools have, I would
>> like to replace our PHP tests (and resources used by tests) with Python 3
>> CGI scripts. I?ve already attempted to convert a few dozen PHP tests and
>> resources to demonstrate that this is both possible and that the resulting
>> Python is comparable to the existing PHP. Additionally, as advertised in
>> Big Sur, PHP is only included for compatibility with legacy software and is
>> not recommended.
>> 
>> There are still a few issues to resolve (namely, an issue with Python 3 on
>> some of our Windows machines), in the mean time, I want to determine if
>> other platforms have any issues with replacing our PHP tests with Python 3.
> 
> 
>  BTW, after you finish the task, can we remove Python 2 supports from all
> Python scripts? Or, should we keep Python 2&3 support until Mojave support
> ends?

The biggest blocker for that right now is 
>, which I’m actively working 
on. I’ll send out a message early next week soliciting a larger discussion 
about removing Python 2 support.

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


[webkit-dev] Replacing PHP with Python in Layout Tests

2021-02-01 Thread Jonathan Bedard via webkit-dev
Hello Contributors,

To help reduce the number of dependencies WebKit’s tools have, I would like to 
replace our PHP tests (and resources used by tests) with Python 3 CGI scripts. 
I’ve already attempted to convert a few dozen PHP tests and resources to 
demonstrate that this is both possible and that the resulting Python is 
comparable to the existing PHP. Additionally, as advertised in Big Sur, PHP is 
only included for compatibility with legacy software and is not recommended.

There are still a few issues to resolve (namely, an issue with Python 3 on some 
of our Windows machines), in the mean time, I want to determine if other 
platforms have any issues with replacing our PHP tests with Python 3.

Jonathan
WebKit Continuous Integration

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


[webkit-dev] Official GitHub Mirror Automatically Syncing

2021-01-06 Thread Jonathan Bedard via webkit-dev
Hey folks,

Just wanted to let everyone know that our GitHub mirror, 
https://github.com/WebKit/WebKit , is being 
automatically updated on SVN commits to trunk, just like the git.webkit.org 
 repositories. Using the GitHub repository for daily 
development or automation is now considered a supported workflow.

At this point, the history of main will remain unchanged, so the hashes of the 
commits along main in https://github.com/WebKit/WebKit 
 will not be changing.

If you haven’t done so already, now is a good time to set up a GitHub account 
and ensure the emails you have used to commit to WebKit are attached to that 
account.

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


Re: [webkit-dev] GitHub Account and Commit Attribution

2020-12-17 Thread Jonathan Bedard via webkit-dev
That should not matter for commit attribution. According to their docs 
<https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address>,

To ensure that commits are attributed to you and appear in your contributions 
graph, use an email address that is connected to your GitHub account, or the 
noreply email address provided to you in your email settings.

Which basically means that keeping your email address private does not prevent 
a dedicated snooper if you already have commits associated with your email 
(because someone could just grab the commit log and find the email), but that 
setting your email to private will not prevent commits from being attributed to 
you.

Jonathan

> On Dec 17, 2020, at 1:02 PM, Darin Adler  wrote:
> 
>> On Dec 17, 2020, at 8:47 AM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> Something we’ve just learned about commit attribution and GitHub is that 
>> adding an email to your GitHub account may not attribute commits that were 
>> pushed to a repository before you added the email. There were a few issues 
>> with history as it stands now, and I will be pushing up the final version of 
>> history in the next few days.
>> 
>> What this means for you now is that it is time to set-up your GitHub account 
>> if you have not already and add any emails you used to commit to WebKit to 
>> your account (GitHub allows multiple emails to be associated with a single 
>> account).
> 
> Do GitHub’s privacy settings matter? My GitHub account now has 
> da...@apple.com associated with it, but I have "Keep my email addresses 
> private” checked in GitHub settings. Does that matter?
> 
> — Darin

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


[webkit-dev] GitHub Account and Commit Attribution

2020-12-17 Thread Jonathan Bedard via webkit-dev
Hey folks,

Something we’ve just learned about commit attribution and GitHub is that adding 
an email to your GitHub account may not attribute commits that were pushed to a 
repository before you added the email. There were a few issues with history as 
it stands now, and I will be pushing up the final version of history in the 
next few days.

What this means for you now is that it is time to set-up your GitHub account if 
you have not already and add any emails you used to commit to WebKit to your 
account (GitHub allows multiple emails to be associated with a single account).

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


Re: [webkit-dev] GitHub Clone Published

2020-12-15 Thread Jonathan Bedard via webkit-dev
To provide a short update:

Thanks to Fuji Hironori who pointed out a class of contributors which were not 
properly imported. Re-writing history again to correct these cases.

This does mean that the history on https://github.com/WebKit/Webkit 
 will be changing again in the next few days.

Jonathan

> On Dec 14, 2020, at 9:28 AM, Jonathan Bedard  wrote:
> 
> Hello contributors,
> 
> This morning, I just finished pushing main with re-written history to 
> https://github.com/WebKit/WebKit . Nothing 
> is yet relying on this new repository yet, so we still have an opportunity to 
> change things. In particular, I’m interested in making sure recent 
> contributions are being correctly attributed. Note that at the moment, we 
> have not migrated all branches yet, although there is an example of a 
> migrated branch (the safari-609-branch, to be specific).
> 
> On December 18th, I intend to advertise https://github.com/WebKit/WebKit 
>  as the future canonical home of the WebKit 
> project, and will be publishing instructions on how to rebase forks of the 
> old https://github.com/WebKit/WebKit-http 
>  repository.
> 
> Jonathan Bedard
> WebKit Continuous Integration

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


[webkit-dev] GitHub Clone Published

2020-12-14 Thread Jonathan Bedard via webkit-dev
Hello contributors,

This morning, I just finished pushing main with re-written history to 
https://github.com/WebKit/WebKit . Nothing is 
yet relying on this new repository yet, so we still have an opportunity to 
change things. In particular, I’m interested in making sure recent 
contributions are being correctly attributed. Note that at the moment, we have 
not migrated all branches yet, although there is an example of a migrated 
branch (the safari-609-branch, to be specific).

On December 18th, I intend to advertise https://github.com/WebKit/WebKit 
 as the future canonical home of the WebKit 
project, and will be publishing instructions on how to rebase forks of the old 
https://github.com/WebKit/WebKit-http  
repository.

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


[webkit-dev] Bugzilla Accounts and contributors.json

2020-12-08 Thread Jonathan Bedard via webkit-dev
Hello contributors,

As of r270538, commit-queue will only respect committer and reviewer 
permissions on the first email in contributor.json. The motivation for this is 
that many contributors have old email addresses that they no longer control 
(usually because of certain email services being deprecated over the years) but 
would still like commits made with those old accounts to be associated to them.

Before landing this change, we identified any contributors which committed via 
commit queue with an account that was not their first email, and have reached 
out to those individuals.

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


Re: [webkit-dev] Commit Authorship on GitHub

2020-12-01 Thread Jonathan Bedard via webkit-dev


> On Dec 1, 2020, at 1:55 PM, Yusuke Suzuki  wrote:
> 
> Hi Jonathan!
> 
>> On Dec 1, 2020, at 8:22 AM, Jonathan Bedard via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> Hello contributors,
>> 
>> I am in the process of modifying one of our Git mirrors of the repository 
>> for permanent use. As part of that modification, I am repairing authorship 
>> of historical commits based on contributors.json. This effort includes our 
>> branches and resolving commits attributed to commit-queue but authored by 
>> contributors. Once this task of rewriting history is completed, I will push 
>> the new repository to GitHub to replace the broken mirror that currently 
>> resides there.
> 
> Does it mean that https://github.com/WebKit/WebKit 
> <https://github.com/WebKit/WebKit> will become an usual repository (not 
> GitHub sync-ed mirror repository) which is mirrored by ourselves?
> Previously, when I tried, GitHub-mirrored repository does not invoke 
> web-hooks correctly, and it was the reason why I needed to create WKR bots.
> But if WebKit in GitHub repository becomes an usual repository (while it is 
> mirrored, it is not mirrored by GitHub side), I think this is a good timing 
> to setting up GitHub <-> slack integration to put commits into #changes and 
> retiring WKR bot (while WebKitBot exists).

It does mean that https://github.com/WebKit/WebKit 
<https://github.com/WebKit/WebKit> will become a normal GitHub repository! That 
being said, I need to set up the automated syncing before we start using 
web-hooks.

Jonathan

> 
> -Yusuke
> 
>> 
>> Since the new repository will have correctly attributed commits, now is a 
>> good time to ensure that the email address (or addresses) that you use or 
>> have used to contribute to WebKit are attached to your GitHub account, since 
>> this is how GitHub connects a user to their contributions.
>> 
>> Also note that GitHub will still just be a mirror for the next few months, 
>> so there is no requirement to have an account with GitHub yet.
>> 
>> Jonathan
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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] Commit Authorship on GitHub

2020-12-01 Thread Jonathan Bedard via webkit-dev
Hello contributors,

I am in the process of modifying one of our Git mirrors of the repository for 
permanent use. As part of that modification, I am repairing authorship of 
historical commits based on contributors.json. This effort includes our 
branches and resolving commits attributed to commit-queue but authored by 
contributors. Once this task of rewriting history is completed, I will push the 
new repository to GitHub to replace the broken mirror that currently resides 
there.

Since the new repository will have correctly attributed commits, now is a good 
time to ensure that the email address (or addresses) that you use or have used 
to contribute to WebKit are attached to your GitHub account, since this is how 
GitHub connects a user to their contributions.

Also note that GitHub will still just be a mirror for the next few months, so 
there is no requirement to have an account with GitHub yet.

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


Re: [webkit-dev] Github mirror is not updating

2020-11-30 Thread Jonathan Bedard via webkit-dev
Not at first, but at the moment, yes, it is intentional. We are working on 
migrating WebKit to a more permanent and complete Git repository, which 
involves editing history. Because of this, we didn’t want to further the 
confusion we already have with two different sets of git hashes. The new 
repository should be pushed in the next week or two

In the mean time, https://git.webkit.org/WebKit-https.git 
 (secure, but different hashes than 
GitHub) and https://git.webkit.org/WebKit.git 
 (uses the same hashes as GitHub), are 
up-to-date mirrors.

Jonathan

> Hi,
> 
> I noticed that the github mirror at https://github.com/webkit/webkit is not 
> getting
> the latest commits from WebKit (it is now about a month behind). Is that 
> intentional?
> 
> Thanks,
> -- 
> Adrien / PulkoMandy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev