[webkit-dev] Sam Sneddon is now a WebKit Reviewer

[Jonathan Bedard via webkit-dev]

Hello folks,

I am happy to announce that Sam Sneddon is now a WebKit Reviewer!

Sam is an expert in Web Platform Tests and our tooling to run layout tests, 
along with Python in general.

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

Re: [webkit-dev] WebKit Tree Closure

[Jonathan Bedard via webkit-dev]

This tree closure has been canceled. ‘main’ will remain open for commits for 
the duration of 2/23 and 2/24.
Thank you for your patience!

Jonathan Bedard
WebKit Continuous Integration

> What: WebKit tree closure
> When: 8pm PT 2/23/2024 until 12pm PT 2/24/2024
> 
> Impact
> Affected services:
> github.com/webkit/webkit
> What: WebKit tree closure
> The default (main) branch of WebKit will be closed during the above time 
> window. It will not be possible to commit changes to this branch during the 
> specified time period. Pull requests and EWS will be unaffected. Merge-queue 
> labels may still be added to pull requests. They will not be processed until 
> the tree is reopened.


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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Jonathan Bedard via webkit-dev]

> Hi,
> 
> Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. 
> Non-reviewers were - of course - encouraged to do informal reviews but they 
> would do so by leaving comments. They would never r+ / r-.
> 
> Since we?ve moved to Github, it seems we have become a lot more lax about 
> this and I have seen non-reviewers approve and reject PRs, not just leaving 
> comments.
> My understanding is that there is no way to prevent this with Github but 
> could we at least make it a policy that non-reviewers should not approve / 
> reject PRs and only leave comments instead?

To provide some context, one of the reasons I didn’t attempt to exactly 
replicate Bugzilla’s behavior when porting our review mechanisms to GitHub was 
that Bugzilla only allows a single reviewer, which meant that an r+ would 
naturally clobber an r-, regardless of who gave the r- initially. Even in 
Bugzilla, non-reviewers could give r+es or r-es, it’s just that Commit-Queue 
wouldn’t respect them.

> The reason I would like us to make enforce this rule is that I find it 
> confusing. We have a lot of new comers in the project and I do not always 
> know if a person is a reviewer or not yet. I imagine it may be even more 
> confusing for non-Apple people.

I agree with this, especially since folks GitHub usernames are not always 
obvious.

> I have in some cases not reviewed patches because I had seen the "green 
> check? and thought the PR already had been approved.
> I have also seen cases of PRs rejected, asking the author to do more work, 
> that I didn?t feel was necessary.
> There is no easy way from the GitHub UI to tell if the person who 
> approved/rejected your PR is actually a reviewer, as far as I know.

I think it’s fair for a non-reviewer to “Request Changes” on a PR, it’s often 
the case that a non-reviewer has comments that should block a change from 
landing. If a reviewer (or even the PR author) thinks that the blocking comment 
has been addressed, they can “re-request review” which will get-rid of symbol 
until the account whose review is requested re-reviews the PR.

I think this also points to the right way to address the confusion for r+es 
(which I think are the bigger issue): if we formally make our policy that 
non-reviewers should not leave a persistent “Approved” checkmark on a PR, we 
could have EWS listen for PR approvals and simply request a re-review any time 
a non-reviewer approves a PR. In practice, this will mean that a non-reviewer 
which approves a PR will have their approval nearly instantly removed by a bot. 
We could even have the bot comment something like “Unofficial r+ from 
non-reviewer ” to make exactly what’s going on clear.

The issue with a policy change like this one is that it’s WebKit reviewers who 
deeply understand the policies of the WebKit project, but it’s non-reviewers 
who need to change their behavior. If we don’t back this policy clarification 
with a tools change, I think non-reviewers are unlikely to be aware project 
policy has changed.

> 
> What do you think?
> 
> Thanks,
> Chris Dumez.

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

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

[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] webkit-dev Digest, Vol 208, Issue 5

[Jonathan Bedard via webkit-dev]

> On Sep 29, 2022, at 4:28 PM, Ryosuke Niwa  wrote:
> 
> 
> 
>> On Sep 29, 2022, at 11:48 AM, Jonathan Bedard via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> 
>>>> On Sep 20, 2022, at 1:52 PM, Brent Fulgham >>> <mailto:bfulg...@apple.com>> wrote:
>>>> 
>>>>> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev 
>>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>>> 
>>>>>> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev 
>>>>>> mailto:webkit-dev@lists.webkit.org> 
>>>>>> <mailto:webkit-dev@lists.webkit.org>> wrote:
>>>>>> 
>>>>>> Documentation is an important part of any open source project, 
>>>>>> especially for a larger project like WebKit. Being able to ramp up 
>>>>>> during the onboarding process, reading up on architectural decisions, 
>>>>>> and learning how to perform common procedures are all features the 
>>>>>> documentation should tackle. WebKit has a large set of documentation 
>>>>>> already, but it is scattered around a wide range of platforms (Trac, 
>>>>>> GitHub Wiki, markdown files in the code, Git commits, etc...), and some 
>>>>>> of the information is out of date.
>>>>> 
>>>>> This ultimately feels like this situation:
>>>>> https://xkcd.com/927/ <https://xkcd.com/927/>
>>>>> 
>>>>> I?ve been working on 
>>>>> https://github.com/WebKit/WebKit/blob/main/Introduction.md 
>>>>> <https://github.com/WebKit/WebKit/blob/main/Introduction.md> for the past 
>>>>> couple of years, and I?d would have preferred to have a collaboration 
>>>>> rather than a competition here.
>> 
>> Right now we have:
>> https://github.com/WebKit/WebKit/wiki
>> https://trac.webkit.org/
>> https://webkit.org/getting-started/
>> https://github.com/WebKit/WebKit/blob/main/Introduction.md
>> 
>> Brandon’s solution is designed to replace the first 2, and he has buy in 
>> from the maintainers of the first two, when his solution is deployed, our 
>> existing wikis will die.
> 
> I don’t think there is a community wide buy-in to replace either 
> documentations / tools at this point. I don’t think people who happen to 
> maintain the infrastructure get to have unilateral say on which tools will 
> get supported or deprecated.

This is an effort to get community wide buy-in.

But it’s also worth noting that services (Trac, in particular) aren’t free to 
maintain, while we don’t have anything forcing action on Trac yet, it is likely 
we will be forced to do something in the future. And folks maintaining 
infrastructure might be forced to unilaterally make decisions in the future if 
the community hasn’t already made a decision. My point in bringing up the 
deprecation of our other two Wiki sources is that I don’t think we’re in the 
“competing standards” situation referenced in the xkcd comic.

> 
>>>>>> I have tested this on macOS and Linux and have found it works extremely 
>>>>>> well. (Windows should be able to use WSL2 at the moment, while a few 
>>>>>> remaining issues get sorted out). The only dependency for this project 
>>>>>> is a recent installation of Swift.
>>>>> 
>>>>> Previously, we?ve rejected Swift as a general purpose programming 
>>>>> languages in WebKit: 
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2014-July/026722.html 
>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2014-July/026722.html> 
>>>>> other than to allow existing C++ code to call into Swift API: 
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031882.html 
>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2021-June/031882.html>
>>>>> 
>>>>> As such, I don?t think we should require having a functional Swift 
>>>>> toolchain as a requirement for contributing to WebKit or its 
>>>>> documentations either.
>>>> 
>>>> DocC is not a requirement to use or participate in this work. It?s simply 
>>>> a ?port? of the documentation that works for our needs. If others prefer 
>>>> to ?build? output documentation from Markdown using a different tool set, 
>>>> they are welcome to contribute those build commands and instructions.
>>> 
>> 
>> Something else wo

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

[Jonathan Bedard via webkit-dev]

>> On Sep 20, 2022, at 1:52 PM, Brent Fulgham  wrote:
>> 
>>> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev 
>>>  wrote:
>>> 
 On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev 
 mailto:webkit-dev@lists.webkit.org>> wrote:
 
 Documentation is an important part of any open source project, especially 
 for a larger project like WebKit. Being able to ramp up during the 
 onboarding process, reading up on architectural decisions, and learning 
 how to perform common procedures are all features the documentation should 
 tackle. WebKit has a large set of documentation already, but it is 
 scattered around a wide range of platforms (Trac, GitHub Wiki, markdown 
 files in the code, Git commits, etc...), and some of the information is 
 out of date.
>>> 
>>> This ultimately feels like this situation:
>>> https://xkcd.com/927/ 
>>> 
>>> I?ve been working on 
>>> https://github.com/WebKit/WebKit/blob/main/Introduction.md 
>>>  for the past 
>>> couple of years, and I?d would have preferred to have a collaboration 
>>> rather than a competition here.

Right now we have:
https://github.com/WebKit/WebKit/wiki
https://trac.webkit.org/
https://webkit.org/getting-started/
https://github.com/WebKit/WebKit/blob/main/Introduction.md

Brandon’s solution is designed to replace the first 2, and he has buy in from 
the maintainers of the first two, when his solution is deployed, our existing 
wikis will die.

I think https://webkit.org/getting-started/ and 
https://github.com/WebKit/WebKit/blob/main/Introduction.md are both designed to 
be too narrow to be a dumping ground for all our documentation. 

>> 
>> Ryosuke: Your document is outstanding, and is a large part of the content we 
>> pulled into the current repo. I don?t think we view this as a competition; 
>> rather we are trying to host a collection of Markdown content in a common 
>> repo that does not have to be pulled and synced with WebKit source and 
>> tests. This provides a lower bar for people interested in contributing 
>> documentation as they do not have to download and sync Gigabytes of WebKit 
>> code to write documentation.
> 
> Who are these people who want to contribute to WebKit?s documentation yet 
> doesn?t already have a clone of WebKit repository? I just can?t think of 
> people who would fit that description.

Mixing together documentation commits with commits which change product code is 
not great, it makes tracking down regressions more difficult for the same 
reasons we like monotonically increasing commit numbers. I think this is a 
trade off well worth it for Introduction.md, but not for something like 
https://github.com/WebKit/WebKit/wiki/Source-Control#identifiers.

It’s also worth calling out that Jon Davis and I have had a similar discussion 
about https://github.com/WebKit/WebKit/tree/main/Websites/webkit.org, that’s 
probably something we shouldn’t be committing to the same repository with all 
our product code.

> 
> (2) is particularly important because many people who are new to WebKit often 
> don?t know what they don?t know. This is why, for example, memory management 
> section appears towards the beginning of the document and the information 
> about adding IDL files is immediately followed by the discussion of JS 
> wrapper lifecycles. With these information now split across multiple files, 
> it?s easy for people to miss out on critical information. In the ideal world, 
> people won?t be adding or editing IDL files before they understood how JS 
> wrappers are managed because not knowing the latter is a sure way of 
> introducing subtle GC bugs.
> 
 A few months ago, I started working on a new documentation solution based 
 on the DocC documentation framework.
>>> 
>>> Was there any discussion as to which documentation framework should be 
>>> used? I?m personally not familiar with DooC documentation, and I?m  
>>> surprised that such an important decision was made unilaterally without 
>>> much discussion on webkit-dev.
>> 
>> We discussed this internally, but today?s message is the first discussion on 
>> this repository that we?ve opened on the webkit-dev mailing list. We wanted 
>> to convince ourselves that the tool worked well, and was easy to use, and 
>> could produce documentation output that would be useful for Apple engineers. 
>> That is not the only intended audience for this work, but is the origin of 
>> this effort which we wanted to make available to others to use and 
>> contribute to.
>> 
>> Those of us who have worked on WebKit for some time can easily remember the 
>> many discussions over the years about documentation efforts of various 
>> types. Lots of people have strong opinions, but few ever contribute despite 
>> their opinions of the right way for the work to be done. You are obviously 
>> part of the group that has contributed heavily, so I am 

Re: [webkit-dev] WebKit is now on GitHub

[Jonathan Bedard via webkit-dev]

I’m aware of the WebKitGTK branches, please reach out about the WPE ones, I’m 
not sure which ones those are.

Absolutely will make sure we’ve migrated everything before delete SVN for good, 
and there will be plenty of warning before we do anything destructive.

Jonathan

> On Jun 23, 2022, at 2:01 PM, Michael Catanzaro  wrote:
> 
> On Thu, Jun 23 2022 at 10:29:55 AM -0700, Jonathan Bedard via webkit-dev 
>  wrote:
>> Let me know if there is any fallout,
> 
> As far as I know, WebKitGTK and WPE WebKit stable branches have not yet been 
> migrated and are now read-only? Let's make sure not to delete SVN until we're 
> certain they have migrated.
> 
> Michael
> 
> 

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

[webkit-dev] WebKit is now on GitHub

[Jonathan Bedard via webkit-dev]

r295779 is the last commit to WebKit’s Subversion repository. 
https://github.com/WebKit/WebKit is now the canonical home of the WebKit 
project! All commits must now go through Commit-Queue, Merge-Queue or 
Unsafe-Merge-Queue.

For the next few weeks, svn.webkit.org and trac.webkit.org will remain 
accessible in a read-only state so we can audit any content we intend to 
migrate to GitHub.

Let me know if there is any fallout,

Jonathan Bedard
WebKit Continuous Integration

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

[webkit-dev] 7 Days Until Retiring Subversion

[Jonathan Bedard via webkit-dev]

Hey folks,

The time has come! On Thursday, June 23rd, we are planning on stopping all 
commits to the Subversion repository hosted on https://svn.webkit.org 
, all future commits will at that point be made on 
https://github.com/WebKit/WebKit . If the 
following is true about your development workflow:

- You use github.com/WebKit/WebKit  as the 
remote for your git checkout of WebKit
- You commit with Commit-Queue, Merge-Queue or Unsafe-Merge-Queue

Then you do not need to change anything about your workflow. Changes which are 
being processed during the transition will be routed to the correct place by 
Commit and Merge Queue. I would like to specifically note that `webkit-patch` 
and the patch workflow in general will continue to work after Subversion is 
frozen. You can check which remote your checkout uses with ‘git remote -v’. 
Please see the migration guide below for details.

If you are still reliant off of git.webkit.org  remotes 
(either WebKit-https.git or WebKit.git), or if you still have a checkout based 
on https://svn.webkit.org , it’s time to migrate those 
checkouts. See https://github.com/WebKit/WebKit/wiki/Migration 
 for details on how to migrate 
from an existing checkout or 
https://github.com/WebKit/WebKit/wiki/Contributing#checking-out-WebKit 
 for 
starting fresh. We intend to keep our defunct remotes available for a few weeks 
to ease the transitions, but starting Thursday, these 3 remotes will not be 
receiving new commits.

Please reach out if you have any issues,

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

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

[Jonathan Bedard via webkit-dev]

> On Jun 3, 2022, at 7:59 AM, Geoffrey Garen  wrote:
> 
>>> What is the goal of this proposal?
>> 
>> The goal is to increase the stability of the build
> 
> Is this goal distinct from preventing regressions from landing? If so, how?
> 
>> , speed up EWS by preventing regressions from landing
> 
> What are some notable cases of recent regressions that have landed because of 
> non-use of commit queue and caused serious problems?

Some recent examples of regressions that would have been prevented by mandatory 
commit/merge-queue as proposed:

https://commits.webkit.org/250940@main <https://commits.webkit.org/250940@main> 
(PR did use Merge-Queue, but we’re missing the feature that would have caught 
the problem)
https://commits.webkit.org/250343@main <https://commits.webkit.org/250343@main> 
(Commit did use Commit-Queue, but skipped layout tests because of a previous 
iteration passed EWS)
https://commits.webkit.org/250791@main <https://commits.webkit.org/250791@main> 
(Should have failed EWS, but flakey tests had different names, cross 
referencing trunk results would have made that obvious)
https://commits.webkit.org/248624@main <https://commits.webkit.org/248624@main> 
(Landed manually, broke the build)

> 
> Do you have any data on how frequent such regressions are, compared to the 
> base rate of regressions that have landed despite use of commit queue?

Commit and Merge queue have basically prevented us from breaking the Mac build, 
the only example of a broken Mac build I can find come from by-passing Commit 
and Merge Queue. Layout test breakages are quite a bit more difficult to reason 
about because breakages tend to not just be platform specific, but 
configuration specific as well.

> 
> Do you have any data on how frequently regressions are resolved by patches 
> that land outside commit queue?

In the last week, we had 200 commits. 50 of those were made through the 
Unsafe-Merge-Queue. Break down is here:

15 were feature work that should have gone through Merge Queue
12 were test gardening
9 were build or test fixes
3 were 3rd party imports
3 were reverts
3 were tooling changes
2 were buildbot changes
2 were contributors.json changes
1 was a documentation change

My proposal would have sent the feature work, gardening work, imports, tooling 
change and documentation change to Merge-Queue rather than Unsafe-Merge-Queue. 
The build and test fixes would have needed modification to their commit 
messages, but were the kind of changes I would want landed via 
Unsafe-Merge-Queue.

> 
>> and reduce demands of post-commit test gardening.
> 
> Is this goal distinct from preventing regressions from landing? If so, how?

I suppose I should have said:
"The goal is to increase the stability of the build, speed up EWS and reduce 
demands of post-commit test gardening by preventing regressions from landing”, 
since build instability, slow EWS and post-commit test gardening are all 
consequences of regressions landing.

> 
>>> What problem are you trying to solve, and with what level of urgency?
>> 
>> Urgency is not high. I started this with the expectation it would be a 
>> somewhat long and contentious discussion. The motivating change is that the 
>> GitHub transition makes this proposal possible, from a technical 
>> perspective, in a way it is not while the project is still backed by 
>> Subversion.
> 
> I don’t understand the premise here. There are lots of ways to enforce commit 
> policy on a Subversion repository.

Kind of. The problem here is that we want to provide enough escape hatches so 
that any committer can quickly repair a broken build, so we have to check not 
just the committer, but the commit itself. This is more analogous to ensuring 
that commit has “Reviewed by” in it’s commit message (something that Subversion 
does not enforce in our repository, despite it being policy) than it is to 
ensuring that the committer has certain privileges. We’ve always implemented 
these kind of checks in buildbot, not the Subversion server, and it’s much 
easier to implement complicated logic that takes into consideration the content 
of the commit in buildbot than it is Subversion hooks.

> On the meta level, while we are still dealing with serious regressions in our 
> workflow caused by git and GitHub, I recommend that we do not push forward 
> with more unrelated sweeping changes to the project and its workflow. Just 
> like in software development, where we need to fix regressions before we can 
> move forward with major feature work, so too in tooling we need to do the 
> same. Otherwise we just pile chaos on top of chaos, and there is no way to 
> know if things are improving or getting worse, and no way to hold ourselves 
> accountable for improvement. 
> 
> Thanks,
> Geoff
> 
>> 

Re: [webkit-dev] Add CODEOWNERS to WebKit

[Jonathan Bedard via webkit-dev]

> On Jun 2, 2022, at 2:53 PM, Alexey Proskuryakov  wrote:
> 
> 
> It seems like we still need to host watchlist CC service though, to support 
> patch workflow - and we'll have separate lists in GitHub and in Bugzilla, 
> unless watchlists are reimplemented.

We would still need to host the current watchlist service, yes. Although we 
wouldn’t have to teach this watchlist how to interact with GitHub. It would 
also be possible (and not too hard) to teach our watchlist service to read the 
CODEOWNERS file, at least in cases where the individual being CCed wasn’t a 
group.

> 
> I believe that while there are stale watchlists entries, newer additions are 
> valid.
> 
> - Alexey
> 
>> 2 июня 2022 г., в 2:19 PM, Jonathan Bedard via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> 
>> написал(а):
>> 
>> Porting is possible, but that would be something that would happen, at the 
>> earliest, a few weeks from now. I does seem to me that the watchlist is out 
>> of date, so a forced-cleanup doesn’t seem like the worst thing.
>> 
>> Jonathan
>> 
>>> On Jun 2, 2022, at 2:21 PM, Chris Dumez >> <mailto:cdu...@apple.com>> wrote:
>>> 
>>> I’m kind of ambivalent/neutral about this. One question though:
>>> 
>>> When adopting CODEOWNERS, will our existing watchlists get ported, or will 
>>> each contributor have to modify CODEOWNERS themselves to match whatever was 
>>> in the watchlists for them?
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>>> On Jun 2, 2022, at 1:12 PM, Jonathan Bedard via webkit-dev 
>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>> 
>>>> Hey folks,
>>>> 
>>>> Yusuke is interested in adding the CODEOWNERS file to the WebKit project 
>>>> (see https://github.com/WebKit/WebKit/pull/1137 
>>>> <https://github.com/WebKit/WebKit/pull/1137>). There have been some 
>>>> objections to this, the two ones I’m aware of:
>>>> - WebKit doesn’t assign “ownership” to pieces of code, so the name is 
>>>> unfortunate
>>>> - The last match “wins”, so if you subscribed to a generic directory early 
>>>> in the file, more specific matches would override that subscription
>>>> 
>>>> Despite these downsides, I think adding the CODEOWNERS file is good for 
>>>> the project for a few reasons:
>>>> - It’s a standard natively supported by GitHub, BitBucket and GitLab and 
>>>> will be familiar to developers
>>>> - File format is more simple than existing watchlist
>>>> - Support for groups and individuals
>>>> - No need for WebKit to host a service (other implementations of 
>>>> auto-CCing would require this)
>>>> 
>>>> I intend to work with Yusuke to land 
>>>> https://github.com/WebKit/WebKit/pull/1137 
>>>> <https://github.com/WebKit/WebKit/pull/1137> and start adopting CODEOWNERS 
>>>> on Monday absent objections that folks think overshadow the benefits of 
>>>> the CODEOWNERS file.
>>>> 
>>>> 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 <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

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

[Jonathan Bedard via webkit-dev]

> On Jun 2, 2022, at 4:41 PM, Geoffrey Garen  wrote:
> 
> 
>> As we move to GitHub, I would like to propose we strengthen our protections 
>> on `main` by making MergeQueue and CommitQueue mandatory. 
> 
> 
> What is the goal of this proposal?

The goal is to increase the stability of the build, speed up EWS by preventing 
regressions from landing and reduce demands of post-commit test gardening.

> What problem are you trying to solve, and with what level of urgency?

Urgency is not high. I started this with the expectation it would be a somewhat 
long and contentious discussion. The motivating change is that the GitHub 
transition makes this proposal possible, from a technical perspective, in a way 
it is not while the project is still backed by Subversion.

Jonathan

> 
> Thanks,
> Geoff
> 
> 
>> On Jun 2, 2022, at 2:35 PM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> As we move to GitHub, I would like to propose we strengthen our protections 
>> on `main` by making MergeQueue and CommitQueue mandatory. This would mean 
>> that with a few exceptions, all changes would need to be built and run 
>> layout tests before they are landed. To spell out what the exceptions I had 
>> in mind are:
>> 
>> - Revert commits, identified by a commit message that starts with 
>> “Unreviewed, revering…” would be exempt
>> - Changes which only modify files that do not effect building or testing 
>> WebKit would be exempt. These files specifically are:
>>  .github/
>>  JSTests/
>>  ManualTests/
>>  metadata/
>>  PerformanceTests/
>>  Tools/
>>   CISuport/
>>   EWSTools/
>>   WebKitBot
>> Websites/
>> - Emergency build and infrastructure fixes, identified by a commit message 
>> that starts with “Emergency build fix” or “Emergency infrastructure fix” 
>> would be exempt
>> - A reviewer who is not the commit author can overwrite this protection by 
>> adding `unsafe-merge-queue` instead of the commit author
>> - Changes which passed an EWS layout test queue within the last 7 days would 
>> skip the layout test check
>> 
>> These exceptions are designed to provide contributors for a way to by-pass 
>> potentially slow checks if extraordinary situations, or in ones where CI has 
>> already validated the change. I think we should keep the ability for any 
>> committer to deploy an emergency fix, because our project has many 
>> contributors in different timezones and with different holiday schedules.
>> 
>> We know that this policy change would potentially slow down development, so 
>> I think these 3 improvements block making MergeQueue and CommitQueue 
>> mandatory:
>> 
>> - run-webkit-tests consulting results.webkit.org to avoid retrying known 
>> flakey or failing tests
>> - Another MergeQueue bot
>> - Xcode workspace builds to speed up incremental builds
>> 
>> Jonathan Bedard
>> WebKit Continuous Integration
>> 
>> ___
>> 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] Proposal: Mandatory Commit and Merge Queue

[Jonathan Bedard via webkit-dev]

As we move to GitHub, I would like to propose we strengthen our protections on 
`main` by making MergeQueue and CommitQueue mandatory. This would mean that 
with a few exceptions, all changes would need to be built and run layout tests 
before they are landed. To spell out what the exceptions I had in mind are:

- Revert commits, identified by a commit message that starts with “Unreviewed, 
revering…” would be exempt
- Changes which only modify files that do not effect building or testing WebKit 
would be exempt. These files specifically are:
 .github/
 JSTests/
 ManualTests/
 metadata/
 PerformanceTests/
 Tools/
 CISuport/
 EWSTools/
 WebKitBot
Websites/
- Emergency build and infrastructure fixes, identified by a commit message that 
starts with “Emergency build fix” or “Emergency infrastructure fix” would be 
exempt
- A reviewer who is not the commit author can overwrite this protection by 
adding `unsafe-merge-queue` instead of the commit author
- Changes which passed an EWS layout test queue within the last 7 days would 
skip the layout test check

These exceptions are designed to provide contributors for a way to by-pass 
potentially slow checks if extraordinary situations, or in ones where CI has 
already validated the change. I think we should keep the ability for any 
committer to deploy an emergency fix, because our project has many contributors 
in different timezones and with different holiday schedules.

We know that this policy change would potentially slow down development, so I 
think these 3 improvements block making MergeQueue and CommitQueue mandatory:

- run-webkit-tests consulting results.webkit.org  
to avoid retrying known flakey or failing tests
- Another MergeQueue bot
- Xcode workspace builds to speed up incremental builds

Jonathan Bedard
WebKit Continuous Integration

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

Re: [webkit-dev] Add CODEOWNERS to WebKit

[Jonathan Bedard via webkit-dev]

Porting is possible, but that would be something that would happen, at the 
earliest, a few weeks from now. I does seem to me that the watchlist is out of 
date, so a forced-cleanup doesn’t seem like the worst thing.

Jonathan

> On Jun 2, 2022, at 2:21 PM, Chris Dumez  wrote:
> 
> I’m kind of ambivalent/neutral about this. One question though:
> 
> When adopting CODEOWNERS, will our existing watchlists get ported, or will 
> each contributor have to modify CODEOWNERS themselves to match whatever was 
> in the watchlists for them?
> 
> Thanks,
> Chris.
> 
>> On Jun 2, 2022, at 1:12 PM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> Hey folks,
>> 
>> Yusuke is interested in adding the CODEOWNERS file to the WebKit project 
>> (see https://github.com/WebKit/WebKit/pull/1137 
>> <https://github.com/WebKit/WebKit/pull/1137>). There have been some 
>> objections to this, the two ones I’m aware of:
>> - WebKit doesn’t assign “ownership” to pieces of code, so the name is 
>> unfortunate
>> - The last match “wins”, so if you subscribed to a generic directory early 
>> in the file, more specific matches would override that subscription
>> 
>> Despite these downsides, I think adding the CODEOWNERS file is good for the 
>> project for a few reasons:
>> - It’s a standard natively supported by GitHub, BitBucket and GitLab and 
>> will be familiar to developers
>> - File format is more simple than existing watchlist
>> - Support for groups and individuals
>> - No need for WebKit to host a service (other implementations of auto-CCing 
>> would require this)
>> 
>> I intend to work with Yusuke to land 
>> https://github.com/WebKit/WebKit/pull/1137 
>> <https://github.com/WebKit/WebKit/pull/1137> and start adopting CODEOWNERS 
>> on Monday absent objections that folks think overshadow the benefits of the 
>> CODEOWNERS file.
>> 
>> Jonathan
>> ___
>> 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] Add CODEOWNERS to WebKit

[Jonathan Bedard via webkit-dev]

Hey folks,

Yusuke is interested in adding the CODEOWNERS file to the WebKit project (see 
https://github.com/WebKit/WebKit/pull/1137 
). There have been some objections 
to this, the two ones I’m aware of:
- WebKit doesn’t assign “ownership” to pieces of code, so the name is 
unfortunate
- The last match “wins”, so if you subscribed to a generic directory early in 
the file, more specific matches would override that subscription

Despite these downsides, I think adding the CODEOWNERS file is good for the 
project for a few reasons:
- It’s a standard natively supported by GitHub, BitBucket and GitLab and will 
be familiar to developers
- File format is more simple than existing watchlist
- Support for groups and individuals
- No need for WebKit to host a service (other implementations of auto-CCing 
would require this)

I intend to work with Yusuke to land https://github.com/WebKit/WebKit/pull/1137 
 and start adopting CODEOWNERS on 
Monday absent objections that folks think overshadow the benefits of the 
CODEOWNERS file.

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

[webkit-dev] ChangeLogs are Deprecated

[Jonathan Bedard via webkit-dev]

As outlined in my email yesterday, Commit-Queue and Merge-Queue both now reject 
any changes that include ChangeLogs.

I will be waiting a few days before actually deleting all of the ChangeLog 
files so that contributors with patches that still contain ChangeLogs can apply 
those patches without conflicts.

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

[webkit-dev] ChangeLog Deprecation in WebKit

[Jonathan Bedard via webkit-dev]

Starting tomorrow, Tuesday May 17th, WebKit will no longer be using ChangeLogs 
and will instead require commit messages in new commits. These were the norm 
when we started the project, but now they are unusual, antiquated, and get in 
the way of common git tooling.

This means that we need a commit message in every patch or PR that's submitted 
for review. From prior discussion, it is very clear that there are legitimate 
downsides too, and I want to take this opportunity to suggest recommended paths 
forward.

You will need to take action if you:
- Have a pure-Subversion checkout
- Draft patches without making local commits
- Draft patches from multiple local commits
- Have patches with ChangeLogs already in bugzilla
- Have pull requests with ChangeLogs

https://github.com/WebKit/WebKit/wiki/Migration 
 covers migration to GitHub 
workflows in general, but Tuesday’s change is quite a bit more narrow in its 
effects. Below I’ve listed the actions you may need to take

- Have a pure-Subversion checkout

Follow https://github.com/WebKit/WebKit/wiki/Migration#subversion 
 to clone 
github.com/WebKit/WebKit  and start developing 
from a GitHub checkout. The patch workflow works just as well from a GitHub 
checkout. One significant difference is that it's not possible to commit 
directly, but this is going away soon as GitHub becomes the source of truth, so 
it is probably not worth migrating to git-svn for. Also, some people find 
git-svn handy to convert between revision formats; we have `git webkit find` as 
a replacement.

- Draft patches without making local commits

Run `git-webkit setup` to configure your local git hooks to provide a WebKit 
commit-message template. Before running `webkit-patch upload`, run `git commit 
-a` to create a local commit with all local changes. To amend that commit, run 
`git commit -a —amend`.

- Draft patches from multiple local commits

EWS will test patches with multiple commits in them, but Commit-Queue will not 
land those patches. If you have a multi-commit patch (or branch) applied 
locally, you need to squash them. I’d recommend `git rebase -i `. To do 
this, run `git rebase -i HEAD~3`, git will then open your editor and offer to 
`pick` the last 3 commits. Keep `pick` for the first listed commit, but use  
`squash` for the other two and close your editor, the last 3 commits will be 
squashed into a single commit.

- Have patches with ChangeLogs

Apply your patch with `webkit-patch apply-from-bug `. If we’ve 
already removed the ChangeLog files from the repository, this patch application 
will fail. Resolve the conflicts, and commit your local changes and draft a 
commit message.

If we haven’t yet removed the ChangeLog files, your patch should apply. In that 
case, make sure you’ve run `git-webkit setup` and commit your local changes 
include the ChangeLog. This will create a commit message derived from your 
ChangeLogs. Then, remove the ChangeLog edits locally, amend your previous 
commit with `git commit -a —amend` and re-upload your ChangeLog free patch.

- Have pull requests with ChangeLogs

Check out your pull request, remove any ChangeLog edits locally and run 
`git-webkit pr --amend`.

Jonathan
WebKit Continuous Integration

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

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Jonathan Bedard via webkit-dev]

I’m measuring from “engineer tells GitHub to land a change”, not “Merge-Queue 
checks out the change”. The basic steps of the process are:

- GitHub sends hook to buildbot
- buildbot validates hook and PR
- buildbot checks out PR
- buildbot inserts reviewer to commit message and ChangeLog
- buildbot runs basic pre-commit checks
- buildbot adds identifier
- buildbot commits
- buildbot updates PR with landed commit
- buidbot comments on PR and bug with information on landed commit
- buildbot closes associated bug

The “commit” step usually happens at 2 minute mark currently, I gave the time 
for the whole process (including bug comments, bug closing, etc). It will be a 
bit faster once we can drop the `git-svn` pieces of this, it’s the “checkout” 
and “add identifier” step that can take longer than you would expect. 10 
minutes is a worst-case scenario when there are already other changes in the 
unsafe queue and some bots are busy with Merge-Queue and Commit-Queue requests, 
so there is only a single available bot serving the unsafe queue.

Jonathan

> On May 11, 2022, at 4:31 PM, Chris Dumez  wrote:
> 
> 
>> On May 11, 2022, at 11:56 AM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> Trying to embed previous replies is going to get messy, will be referencing 
>> those replies but not embedding them.
>> 
>> Unsafe-Merge-Queue should be very fast, I haven’t seen anything take longer 
>> than 10 minutes from label application to landing or rejection. The average 
>> case is 3-4 minutes. We’re aware of what the architectural problem with 
>> Commit-Queue is that slows down the fast path, Unsafe-Merge-Queue has fixed 
>> that. The solution we used isn’t transferable to Commit-Queue.
> 
> I personally don’t think that delaying a critical build fix / gardening by 10 
> minutes is OK. It’s called “unsafe-merge-queue”, why does it take this long 
> to commit? Why isn't it as fast as "generate a unique identifier and git 
> push”?
> Sure, I have no idea how the unsafe-merge-queue does but it is hard for me to 
> imagine it should take more than 1 minute given what it needs to do and given 
> that it should need to do extremely little testing given that it is “unsafe”.
> 
> 4 to 10 minutes is nowhere near as fast as `git svn dcommit` and is therefore 
> a pretty large regression.

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

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Jonathan Bedard via webkit-dev]

Trying to embed previous replies is going to get messy, will be referencing 
those replies but not embedding them.

Unsafe-Merge-Queue should be very fast, I haven’t seen anything take longer 
than 10 minutes from label application to landing or rejection. The average 
case is 3-4 minutes. We’re aware of what the architectural problem with 
Commit-Queue is that slows down the fast path, Unsafe-Merge-Queue has fixed 
that. The solution we used isn’t transferable to Commit-Queue.

Manual landing from a Subversion checkout isn’t broken by this proposal 
(although that is coming very soon), but it will be made much more painful. In 
my response to Geoff, I said:

We would be immediately ending support for _landing_ patches posted from a 
Subversion checkout

This is a deliberately narrow statement. Because SVN doesn’t have local commit 
messages, we can’t generate (or apply) patches containing commit messages. You 
can still land from a raw Subversion checkout, but you would need to manually 
draft a compliant commit message. `git svn dcommit` from a git-svn checkout is 
also unaffected (and what Commit-Queue and Merge-Queue are using and will 
continue to use) because git checkouts can apply patches with commit messages.

To R. Niwa’s point that he would “never want to make a local commit”, that’s 
not going to be possible in the very near future, and there isn’t much we can 
do tooling wise to change this fact. As mentioned in my initial email, 
discussions around placing commit messages in files prior to merge for review 
don’t seem to be headed towards a resolution quickly, and the active harm 
ChangeLogs are causing to development is making their deprecation more urgent 
than the aforementioned discussion would seem to be resolving.

Lastly, Chris did mention this, but just to confirm what he said, GitHub 
checkouts can use `git svn` too, there are a few more “yes, buts” to it (`git 
svn rebase` is to be avoided), as Chris mentioned, `git-webkit setup-git-svn` 
does work in GitHub checkouts.

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

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Jonathan Bedard via webkit-dev]

> On May 10, 2022, at 2:46 PM, Geoffrey Garen  wrote:
> 
> Do I undertand correctly that the proposal here is
> 
>   (a) Immediately Deprecate ChangeLogs

Yes

>   (b) Immediately end support for posting patches from Subversion 
> checkouts?

We would be immediately ending support for _landing_ patches posted from a 
Subversion checkout. EWS would continue to accept and test patches posted from 
Subversion checkouts.

> If so, do you know how many regular WebKit contributors still post patches 
> from Subversion checkouts, and, if that number is not zero, what their 
> schedule is for migrating to git, and whether they need anything from our 
> tools engineers to make that migration smooth?

We don’t know how many contributors still post patches from Subversion 
checkouts, and we actually can’t easily answer this question because we’ve had 
feature parity between Subversion and git-svn checkouts for many years now. 
There are a few types of changes that aren’t compatible with the patch workflow 
in general, but those types of changes are a) rare and b) supported in the 
pull-request workflow

> 
> Seems… problematically forward-looking… to propose immediate migration 
> without that data.
> 
> Thanks,
> Geoff
> 
>> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> A few weeks ago, I started a discussion about deprecating ChangeLogs. In 
>> that time, we’ve had more folks using the pull-request workflow and more 
>> folks using newer versions of `git` which break automatic ChangeLog 
>> rebasing. I propose that on Monday, May 16th, we implement the following 
>> policy changes for the WebKit project:
>> 
>> - Commits no longer require ChangeLogs, they instead require commit messages
>> - Commit messages are in the format of `prepare-ChangeLog --no-write`
>> 
>> Pull-request workflows based on `git-webkit` already support this workflow 
>> well, and `git-webkit setup` creates a `prepare-commit-msg` hook that will 
>> appropriately format commit messages. In addition, `git format-patch` allows 
>> us to create a patch which contains a commit message. This means that 
>> contributors still using patch workflows from a git or git-svn checkout will 
>> be able to upload compliant patches to bugzilla.
>> 
>> This will, however, break contributors using pure-Subversion checkouts. This 
>> is something that’s going to be happening in the very near future as we 
>> deprecate Subversion entirely, so I think this is an acceptable cost in 
>> exchange for fully supporting native git workflows.
>> 
>> The last thing I’d like to note is that a full git-native commit message 
>> policy now is something we can modify in the future if we find that 
>> reviewing commit messages with “Quote reply” comments is not sufficient, but 
>> resolving project disagreements on how or if to address deficiencies in 
>> GitHub commit message review don’t seem to be headed towards a resolution 
>> quickly.
>> 
>> Jonathan
>> WebKit Continuous Integration
>> 
>> ___
>> 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] Proposal: Immediate Deprecation of ChangeLogs

[Jonathan Bedard via webkit-dev]

A few weeks ago, I started a discussion about deprecating ChangeLogs. In that 
time, we’ve had more folks using the pull-request workflow and more folks using 
newer versions of `git` which break automatic ChangeLog rebasing. I propose 
that on Monday, May 16th, we implement the following policy changes for the 
WebKit project:

- Commits no longer require ChangeLogs, they instead require commit messages
- Commit messages are in the format of `prepare-ChangeLog --no-write`

Pull-request workflows based on `git-webkit` already support this workflow 
well, and `git-webkit setup` creates a `prepare-commit-msg` hook that will 
appropriately format commit messages. In addition, `git format-patch` allows us 
to create a patch which contains a commit message. This means that contributors 
still using patch workflows from a git or git-svn checkout will be able to 
upload compliant patches to bugzilla.

This will, however, break contributors using pure-Subversion checkouts. This is 
something that’s going to be happening in the very near future as we deprecate 
Subversion entirely, so I think this is an acceptable cost in exchange for 
fully supporting native git workflows.

The last thing I’d like to note is that a full git-native commit message policy 
now is something we can modify in the future if we find that reviewing commit 
messages with “Quote reply” comments is not sufficient, but resolving project 
disagreements on how or if to address deficiencies in GitHub commit message 
review don’t seem to be headed towards a resolution quickly.

Jonathan
WebKit Continuous Integration

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

Re: [webkit-dev] webkit-patch land behavior change

[Jonathan Bedard via webkit-dev]

For now, `webkit-patch land-unsafe` would be the answer.

In the future, new contributors would need an existing committer to add the 
`merge-queue` label to a PR which adds the new contributor to contributors.json

Jonathan

> On Apr 27, 2022, at 12:16 AM, Manuel Rego Casasnovas  wrote:
> 
> 
> 
> On 26/04/2022 21:58, Jonathan Bedard via webkit-dev wrote:
>> As we move closer to transitioning away from Subversion, I’ve change 
>> ‘webkit-patch land’ to use commit-queue instead of directly committing a 
>> local change from a contributor’s machine 
>> (https://github.com/WebKit/WebKit/pull/392). ‘git-webkit land-unsafe’ will 
>> allow contributors to directly land to Subversion for the time being, 
>> although after we transition to GitHub, will also use commit-queue and 
>> prefix “fast-cq” to uploaded patches to bypass building and testing.
> 
> If I remember correctly when you're accepted as committer you have to do
> a first manual commit adding you to the contributors.json file; and I
> guess people are using "webkit-patch land" for that (see example [1]).
> 
> Would the new contributors be able to land that first commit with the
> commit-queue behavior?
> 
> Cheers,
>  Rego
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=237634

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

[webkit-dev] webkit-patch land behavior change

[Jonathan Bedard via webkit-dev]

Hey folks,

As we move closer to transitioning away from Subversion, I’ve change 
‘webkit-patch land’ to use commit-queue instead of directly committing a local 
change from a contributor’s machine 
(https://github.com/WebKit/WebKit/pull/392). ‘git-webkit land-unsafe’ will 
allow contributors to directly land to Subversion for the time being, although 
after we transition to GitHub, will also use commit-queue and prefix “fast-cq” 
to uploaded patches to bypass building and testing.

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

Re: [webkit-dev] ChangeLog Deprecation Plan

[Jonathan Bedard via webkit-dev]

> It seems to me that you can write a script that just applies a patch while
> ignoring changes to each change log file, then separately prepend each
> change log entry. I don't see why such a script would behave differently
> for reverting multiple commits or rebasing a feature onto a branch. In
> those cases where codebase has enough divergence, merge conflicts are
> probably more of an issue with the codebase itself, and not change log
> entries.

There are many types of changes which are not compatible with patches. “Write a 
change which applies a patch” is not a general solution. It wasn’t a general 
solution in Subversion, and it’s not a general solution in git. Speaking as the 
person who has to maintain our patch workflows, there are many edge cases to 
patch workflows that tend to bite you with precisely the kind of large changes 
which are difficult to manually sift through. Patch workflows also represent a 
huge risk for Apple’s software update branches where changes are cherry-picked 
by engineers who aren’t familiar with the technical details of the changes 
their cherry-picking. These workflows have already been using git for years at 
this point because patches do not work reliably for this type of work. 

> .. or robust solution. Bots need maintenance and intervention, and a bot with
> commit access has another set of issues. Repository admins occasionally
> rotating ChangeLogs is going to be less expensive than a bot doing it.
> 
> Either way, it doesn't seem like this is a higher cost issue compared to
> all WebKit contributors having to change their workflows.

We are moving to git. Workflows _are_ changing. I’m interested in making sure 
the workflows can achieve the same things the old ones did, not in preserving 
the old workflows.

> 
> folks familiar with git won?t realize what has happened until they see
> their PR diff), ?mandatory? is a bit tougher because we can?t prevent folks
> from filing a pull request without using tooling. At that point, we?re
> where we are today with PR template that encourages tool usage, explains
> how to craft a PR the ways tools do it and then reviewers acting as a
> gate-keeper. The last point is more about project policy than it is tooling.
> 
> We should automatically reject such PR requests.

We should not automatically reject PRs made in good faith.

One of the reasons we’re moving to GitHub is to make the project more 
approachable for new contributors. Having a machine rejects PRs because a 
contributor is not familiar with project norms goes against this goal.

> … judgments about personal preferences for local development. From my
> discussions with folks, it seems that the project is pretty evenly split on
> --amend commits, with some contributors preferring them and others
> preferring to make multiple commits. My purpose in bringing up --amend
> commits is that one of the things I?ve heard folks find useful about
> ChangeLogs is the ability to iteratively build them, which is something
> that does have a parallel in raw git workflows.
> 
> No, my option isn't between amending a commit vs. making multiple commits.
> I really don't like making *any local commits* at all. I want to work on a
> patch without ever making local commits, and upload whatever change I may
> have relative to the main branch's HEAD is.

Our tooling supports and will continue to support workflows where the tooling 
automatically makes commits for you. Discussions of other workflows is 
important because we don’t want to build extra tooling for the project if there 
is already a native git workflow which address a specific concern.

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

Re: [webkit-dev] ChangeLog Deprecation Plan

[Jonathan Bedard via webkit-dev]

> Message: 2
> Date: Mon, 18 Apr 2022 10:33:03 -0700
> From: Ryosuke Niwa 
> To: Jonathan Bedard 
> Cc: WebKit Development 
> Subject: Re: [webkit-dev] ChangeLog Deprecation Plans
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> On Mon, Apr 18, 2022 at 8:30 AM Jonathan Bedard via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> 
>> As we migrate WebKit from Subversion to git, I would like to migrate the
>> project away from ChangeLogs. The reason for this is that ChangeLogs make
>> some of the features of git hard to use, namely, cherry-picking commits
>> between branches requires conflict resolution every time.
>> 
> 
> Isn't this something that can be easily resolved with a merge script?

For simple cases, yes. But with something like a multi-commit revert or 
rebasing a feature onto a different branch, merge scripts stop working pretty 
quickly. It’s usually, It might be possible to write a merge script to handle 
these cases, but it’s by no means “easy” in the general case. It’s also worth 
noting that the cases that are more complicated also tend to be the ones with 
the most urgency attached to them.

> 
> Rotating ChangeLogs is also moderately difficult in git with locked down
>> commit access like our project has, only repository administers would, in
>> practice, be able to rotate ChangeLogs.
>> 
> 
> It seems like we can just automate this by introducing a change log
> rotating bot, which has the same privilege as commit queue.

Anything that starts with “we can just have a bot which…” is not a simple or 
robust solution. Bots need maintenance and intervention, and a bot with commit 
access has another set of issues. Repository admins occasionally rotating 
ChangeLogs is going to be less expensive than a bot doing it.

> 
> So these two arguments seem rather weak.
> 
> Lastly, ChangeLogs are uncommon in git based projects, so new contributors
>> will find them difficult to manage.
>> 
> 
> This might be the strongest argument in favor of deprecating change logs.
> 
> 2) We need a way to comment on commit messages in review
>> Current tooling sets the pull request description as the commit message,
>> ?Quote Reply? kind of provides a way to inline comment, although it?s not
>> the formal review UI
>> *Proposal*: Tooling should support a ?COMMIT_MESSAGE? file in each pull
>> request commit that becomes COMMIT_MESSAGE when a pull request is landed
>> 
> 
> This needs to be a mandatory / automatic system, not opt-in. I want to
> comment on commit messages as a reviewer. As a patch author, I don't care
> whether it can be easily commented on or not.
> 
> But if this is a required thing, then new contributors would have to learn
> that this file is auto-generated or needs to be edited manually in some
> cases so getting rid of change logs may not necessarily reduce the
> cognitive load in comparison to keeping the status quo (i.e. keeping change
> log files).

We can make it automatic for folks using tooling (and in such a way that folks 
familiar with git won’t realize what has happened until they see their PR 
diff), “mandatory” is a bit tougher because we can’t prevent folks from filing 
a pull request without using tooling. At that point, we’re where we are today 
with PR template that encourages tool usage, explains how to craft a PR the 
ways tools do it and then reviewers acting as a gate-keeper. The last point is 
more about project policy than it is tooling.

> 
> 3) Edit commit messages while creating a change, not just when committing
>> the change
>> The ?overwrite? workflow already sort of support this idea by using amend
>> commits instead of appending commits to an existing branch
>> *Proposal*: The above ?COMMIT_MESSAGE? file workflow would allow
>> iterative building of a commit message before committing
>> 
> 
> I absolutely despise --amend commits. It's the most annoying thing I have
> to do whenever I'm creating patches in a git clone.

I do not think it is the appropriate place for the WebKit project to make 
judgments about personal preferences for local development. From my discussions 
with folks, it seems that the project is pretty evenly split on --amend 
commits, with some contributors preferring them and others preferring to make 
multiple commits. My purpose in bringing up --amend commits is that one of the 
things I’ve heard folks find useful about ChangeLogs is the ability to 
iteratively build them, which is something that does have a parallel in raw git 
workflows.

The COMMIT_MESSAGE approach, I believe, supports both --amend and amend 
workflows quite well.

> 
> I like the COMMIT_MESSAGE and hooks proposals because they are opt-in.
>> Contributors who w

[webkit-dev] ChangeLog Deprecation Plans

[Jonathan Bedard via webkit-dev]

As we migrate WebKit from Subversion to git, I would like to migrate the 
project away from ChangeLogs. The reason for this is that ChangeLogs make some 
of the features of git hard to use, namely, cherry-picking commits between 
branches requires conflict resolution every time. Rotating ChangeLogs is also 
moderately difficult in git with locked down commit access like our project 
has, only repository administers would, in practice, be able to rotate 
ChangeLogs. Lastly, ChangeLogs are uncommon in git based projects, so new 
contributors will find them difficult to manage.

Currently, our git tooling makes very little effort to either support 
ChangeLogs or to provide alternatives. I have listed bellow some of the reasons 
I understand folks to like ChangeLogs along with possible git-based solutions, 
if necessary.

1) Subversion commit messages are stored server side, local development needs a 
copy
git doesn’t have this problem. We have a local record of commit 
messages in every checkout.
2) We need a way to comment on commit messages in review
Current tooling sets the pull request description as the commit 
message, “Quote Reply” kind of provides a way to inline comment, although it’s 
not the formal review UI
Proposal: Tooling should support a “COMMIT_MESSAGE” file in each pull 
request commit that becomes COMMIT_MESSAGE when a pull request is landed
3) Edit commit messages while creating a change, not just when committing the 
change
The “overwrite” workflow already sort of support this idea by using 
amend commits instead of appending commits to an existing branch
Proposal: The above “COMMIT_MESSAGE” file workflow would allow 
iterative building of a commit message before committing
4) Using git commands to view commit messages is hard
There don’t seem to be many projects which have a solution for this. In 
practice, it seems that reducing the scope of messages shown by restricting 
history to a specific directory or even file is one solution, another is 
shorter commit messages
Proposal: Have Tools/Scripts/git-webkit setup configure hooks in 
contributors local git repositories to lay down CommitMessages.history files on 
merge, checkout and commit which contain the last 5000 commit messages. We can 
put these in similar places to where ChangeLogs are today, although we would 
likely want them in fewer places because this will increase local compute time 
on many git operations. We could also make this a configurable setting so that 
engineers who are more comfortable with the raw command line tooling do not 
have to deal with slower git operations.

I like the COMMIT_MESSAGE and hooks proposals because they are opt-in. 
Contributors who wish to use native git tooling to contribute and interact with 
the project do not have to use either tool, but the tools are compatible enough 
with native git workflows that contributors who find editing and viewing commit 
messages primarily in a text editor

Looking forward to the discussion,

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

[webkit-dev] WebKit and GitHub Update

[Jonathan Bedard via webkit-dev]

It is now the time to start widespread testing of pure git checkouts for 
WebKit. Commit queue has been reimplemented for GitHub, so you don't need a 
Subversion or git-svn checkout for changes to trunk/main that aren’t modifying 
SVN properties.

Over the past few months, we’ve been working on transitioning the WebKit 
project away from Subversion and to `git` hosted by GitHub. While we still have 
a few weeks of work left, we wanted to announce that the WebKit project now 
supports GitHub pull-requests for developing, reviewing and landing changes. 
We’d like to encourage folks to try out these new workflows to identify bugs 
and provide feedback.

To get started, migrate your local WebKit checkouts to the GitHub version 
(documentation is available at https://github.com/WebKit/WebKit/wiki/Migration 
), review our GitHub 
contribution documentation at 
https://github.com/WebKit/WebKit/wiki/Contributing#contributing-code 
, and 
start creating some pull requests!

We will be collecting bugs and feedback under our umbrella bug, 
https://bugs.webkit.org/show_bug.cgi?id=239082 
.

It is worth noting that while we are currently displaying EWS results via 
GitHub’s native checks UI, we have a plan underway to add a dynamic comment 
belonging to EWS that will contain information similar to the bubbles on 
bugs.webkit.org . 

Lastly, we have no plans yet to deprecate patch workflows.  As mentioned in the 
migration documentation, `webkit-patch` will continue to work inside GitHub 
checkouts, so it is possible to use both the pull-request workflow and patch 
workflow from the same checkout.

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 Labels

[Jonathan Bedard via webkit-dev]

Hey folks,

We’re in the final stage of bringing up support for GitHub pull-requests. To 
support this effort, we’re starting to add labels to our project. We intend to 
use labels as a replacement for commit-queue flags and 
Product/Component/Version fields in bugzilla. Before our tools are too reliant 
on specific label names, we wanted to solicit feedback to see if folks had 
specific opinions on certain categories. Bellow I have some preliminary 
thoughts on what labels the project would find helpful: 

EWS and Merge-Queue labels:
merge-queue (green): Applied to send a PR to merge-queue (equivalent of 
a modern cq+)
fast-merge-queue (green): Applied to send a PR to merge-queue, but skip 
building and testing
merging-blocked (purple): Applied to prevent a change from being merged 
(equivalent of a modern cq-)

Component labels (all white)
Use our existing bugzilla component labels and descriptions

Version labels (all grey)
Use our existing bugzilla version labels and descriptions

Misc:
regression (red): Addresses a problem that did not previously exist

It’s worth noting that changing a labels name does apply to existing labels of 
that name, so any decisions we make now can be modified without too much 
disruption.

Existing labels:
https://github.com/WebKit/WebKit/labels 


Excited to here your thoughts,
Jonathan___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Removing Python 2 in WebKit

[Jonathan Bedard via webkit-dev]

Hey folks,

The macOS 12.3 seed remove Python 2. Most of WebKit’s tools are already Python 
3 compatible, and in the last few weeks, we changed a number of buildbot 
invocation and shebangs so that workflows critical to the project are Python 3 
by default. There are still a number of scripts which are Python 2 by default, 
though. Bellow, all of those scripts are listed. If a script important to your 
workflow is listed, now is a good time to help the project out by converting 
that script to Python 3.

Tools/wpe/jhbuildrc
Tools/lldb/dump_class_layout_unittest.py
Tools/lldb/lldb_webkit_unittest.py
Tools/glib/common.py
Tools/glib/api_test_runner.py
Tools/glib/generate-inspector-gresource-manifest.py
Tools/glib/svn-revision
Tools/Scripts/check-for-duplicated-platform-test-results
Tools/Scripts/compare-webkit-configurations
Tools/Scripts/read-checksum-from-png
Tools/Scripts/check-for-invalid-symbols-in-version-script
Tools/Scripts/sync-feature-defines
Tools/Scripts/dump-webkit-tests-run
Tools/Scripts/run-web-platform-tests
Tools/Scripts/check-inspector-strings
Tools/Scripts/import-w3c-performance-wg-tests
Tools/Scripts/export-w3c-performance-wg-tests
Tools/Scripts/malloc-tree
Tools/Scripts/update-test-expectations-from-bugzilla
Tools/Scripts/parse-gc-phase-timings
Tools/Scripts/rebase-patch-after-webkit-move
Tools/Scripts/merge-result-jsons
Tools/Scripts/make-dist
Tools/Scripts/webkit-filter-log
Tools/Scripts/update-webkit-flatpak
Tools/Scripts/export-w3c-test-changes
Tools/Scripts/import-w3c-tests
Tools/Scripts/compare-results
Tools/Scripts/webkit-flatpak
Tools/Scripts/check-for-global-bss-symbols-in-webkitgtk-libs
Tools/Scripts/browserperfdash-benchmark
Tools/Scripts/mark-jsc-stress-test
Tools/Scripts/generate-win32-export-forwards
Tools/Scripts/check-for-platform-layering-violations
Tools/Scripts/find-duplicate-files
Tools/Scripts/import-webdriver-tests
Tools/Scripts/sampstat
Tools/jhbuild/jhbuildrc_common.py
Tools/jhbuild/jhbuild-wrapper
Tools/WebKitArchiveSupport/run-webkit-archive
Tools/CISupport/ews-app/manage.py
Tools/gtk/jhbuildrc
Tools/gtk/ycm_extra_conf.py
Tools/CygwinDownloader/cygwin-downloader.py

Thanks for your help,
Jonathan Bedard___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Recommended GitHub Settings

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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