from:"Michael Catanzaro"


Hi,

Relevant to [1], could someone please check what Safari's current UA 
string is, please? This is important to help me make sure WebKitGTK 
fakes the Safari user agent as well as possible. In particular, I'd 
like to know the version numbers used in the UA. I had thought we were 
frozen on:


Version/11.0 Safari/605.1.15

forever, but perhaps the Version/ component is not frozen and we're up 
to Version/12.0 or Version/12.1 now? I hope the 605.1.15, at least, is 
still frozen.


Also, for those naughty websites that require we use some serious 
fakery and pretend to be macOS, we currently use the string "Macintosh; 
Intel Mac OS X 10_13_4". I understand that Apple's previous attempt to 
freeze that value was not successful, so we still need to update this 
from time to time. What does it look like on, say, Mojave or Catalina?


Thanks,

Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=199745


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

Re: [webkit-dev] What's the current Safari UA?



I received a good answer and will upgrade our versions accordingly. 
Thanks.



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

Re: [webkit-dev] Moving to Python 3

On Fri, Jul 12, 2019 at 2:18 PM, Jonathan Bedard  
wrote:
The trouble I foresee us encountering with any scheme which attempts 
a conversion which retains both Python 2.7 and Python 3 compatibility 
is code like this:


Is python2 support required for a well-motivated transitional purpose?

I had previously proposed making all our scripts work with both python2 
and python3 only because I thought Apple was going to require python2 
indefinitely. Now that you're interested in this transition, there's 
probably no need to continue python2 support. Anyone building WebKit on 
older versions of macOS can reasonably be expected to manually install 
python3, right? And it's clear that you're prepared to do this for 
infrastructure/bots already.


Then million-dollar question is: what shebangs will we use for our 
scripts? Will #!/usr/bin/env python3 work for Apple?


Michael


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

Re: [webkit-dev] Moving to Python 3


On Fri, Jul 12, 2019 at 5:22 PM, Ryosuke Niwa  wrote:
I frequently do WebKit development in older versions of macOS to 
diagnose old OS specific regressions, and having to install Python 3 
each time I install an old OS is too much of a trouble.


I understand it would be a hassle. :/ But please consider it relative 
to the additional difficulty of rewriting all of webkitpy to support 
multiple versions of python at the same time, or setting up a wrapper 
layer of bash scripts around all of our python scripts to enter a 
virtualenv before executing the real script.


Michael


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

Re: [webkit-dev] Moving to Python 3

2019-07-13 Thread Michael Catanzaro

On Sat, Jul 13, 2019 at 6:02 PM, Maciej Stachowiak  
wrote:
This is exactly what virtualenvs can do. And this is how we should do 
it IMO, even for systems that natively have some version of Python 3.


I guess that's fine for everything not required by the CMake build, 
e.g. build-webkit and webkitpy. That's probably 99% of our python code.


Scripts required by the CMake build should use system python3 though, 
not the virtualenv. I guess that's 1% or less of our python. OK?


Michael


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

Re: [webkit-dev] Moving to Python 3

2019-07-14 Thread Michael Catanzaro

On Sat, Jul 13, 2019 at 9:26 PM, Maciej Stachowiak  
wrote:

Can you clarify why this is needed?


Well it just wouldn't seem very kosher to use a virtualenv for the 
serious work of performing real distro builds, right? In contrast to 
developer scripts for developer convenience, where I'd say it's 
perfectly fine to do whatever we want. But official builds should 
surely be performed using system dependencies only.


Anyway, it doesn't seem like a problem. From searching for 'python' in 
my build.ninja, I find:


JSC:

ud_itab.py
generateWasmOpsHeader.py
generateWasmValidateInlinesHeader.py
generateWasmB3IRGeneratorInlinesHeader.py
create_regex_tables
generateYarrUnicodePropertyTables.py
generateIntlCanonicalizeLanguage.py
KeywordLookupGenerator.py
generate-inspector-protocol-bindings.py
generate-js-builtins.py
generateYarrCanonicalizeUnicode
generate-combined-inspector-json.py
jsmin.py
cssmin.py
make-js-file-arrays.py

WebCore:

create-html-entity-table
create-http-header-name-table
makeSelectorPseudoClassAndCompatibilityElementMap.py
makeSelectorPseudoElementsMap.py

WebKit:

generate-message-receiver.py
generate-messages-header.py

WebInspectorUI:

copy-user-interface-resources.pl (perl script that runs some python)

Tools:

generate-inspector-gresource-manifest.py

It's possible I've missed some, but that's probably most of them. 
Basically all the scripts under Source/ -- the scripts that are really 
required to build -- and that one platform-specific exception under 
Tools/, shouldn't require a virtualenv IMO. That doesn't seem too 
difficult to ensure. We could either have them use the virtualenv only 
optionally if it's somehow already available (I'm not familiar with how 
it works) or only if the scripts detect that webkitpy exists, or just 
make this subset of scripts compatible with both python2 and python3 
for the next couple years.


In contrast, the vast majority of our python scripts are not required 
to build. They live under Tools/Scripts, are only used by developers, 
and are not included in release tarballs at all. That includes all of 
webkitpy, anything used by build-webkit, anything used by 
run-webkit-tests, etc. I'd say we can go crazy here. You get a 
virtualenv, you get a virtualenv, everybody gets a virtualenv!


Michael


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

Re: [webkit-dev] Spam and indexing

2019-04-22 Thread Michael Catanzaro

Not indexing bugs.webkit.org will be sad for people who won't be able 
to find bugs they may be interested in via search engines... but those 
people are probably not WebKit developers working with WebKit on a 
daily basis. For us, it's just annoying to deal with the spam. I would 
turn off the indexing if we think it could make a difference.




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

Re: [webkit-dev] Spam and indexing

2019-04-22 Thread Michael Catanzaro

On Mon, Apr 22, 2019 at 11:06 AM, Konstantin Tokarev 
 wrote:
Another possible way is to disable self-registration for new users, 
similarly

to what LLVM project did [1].


GCC Bugzilla did this a long time ago.

It will make it really hard to convince users to report bugs. I would 
try deindexing first, since it's a smaller hammer. Then we could try 
this if that fails.


Michael


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

Re: [webkit-dev] Requesting feedback about EWS comments on Bugzilla bugs

2019-06-16 Thread Michael Catanzaro

1-4 all seem uncontroversial, especially with Tim's suggested 
improvement to immediately leave a "some queues failed" comment.


On Sat, Jun 15, 2019 at 11:13 PM, Aakash Jain  
wrote:
5) Do not comment on bugzilla bug at all, instead send email to the 
author of the patch.
Pros: less noisy, also this will allow to include more detailed 
information about the failure in email.
Cons: reviewers would have to click status-bubbles to see the 
failures, failure information is not immediately present in the 
comments.


Well I think this would be OK, but next we'll be complaining about the 
emails. The underlying problem is excessive test flakiness. We're just 
not doing a very good job of tracking flaky tests and EWS isn't good at 
detecting flaky tests automatically. (Often a flaky test will fail 
twice in the same run, and that gets detected as a test failure.) 
Instead of reporting bugs for such tests, we're ignoring them because 
there are so many and we're so used to it.


commit-queue is able to report bugs when it detects a flaky patch, but 
EWS doesn't do this. That might be a positive change. Of course, EWS 
would need to be smart enough to not report a bug if the flakiness is 
triggered by the patch itself, which might not be simple to determine.


I don't have any concrete suggestions here. Just brainstorming.


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

Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

2019-11-01 Thread Michael Catanzaro


On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:

Namely, some people write a lambda as:
auto x = [] () { }

with a space between [] and () while others would write it as:

auto x = []() { }


: I omit the () when there are no parameters, as in these examples.

No preference on spacing.


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

Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview

2019-10-11 Thread Michael Catanzaro




Hi Ryan,

This is https://bugs.webkit.org/show_bug.cgi?id=202321

Michael


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

Re: [webkit-dev] Introducing a minimum ICU version for WebKit




On Thu, Apr 9, 2020 at 11:49 am, Alexey Proskuryakov  
wrote:


The license is not BSD or LGPL, so that's one aspect to consider.

Why exactly are distros unwilling to update ICU?

- Alexey


Distros would upgrade to newer minor releases of the library, but 
updating system packages to new major versions is not allowed in most 
stable distros.


Sometimes distros make exceptions (e.g. for WebKitGTK, which is special 
due to very high number of CVEs), but ICU does not warrant an 
exception. There are probably hundreds of applications using ICU in 
distros, if not more. Who knows what might break!



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

Re: [webkit-dev] Introducing a minimum ICU version for WebKit

On Thu, Apr 9, 2020 at 2:48 pm, Michael Catanzaro 
 wrote:
Sometimes distros make exceptions (e.g. for WebKitGTK, which is 
special due to very high number of CVEs), but ICU does not warrant an 
exception. There are probably hundreds of applications using ICU in 
distros, if not more. Who knows what might break!


Also, sadly ICU does not maintain a stable API or ABI. So every 
application and library using ICU would need to be rebuilt and updated 
at the same time. Then the update would break any custom software that 
users have using the system ICU. Such an update would go badly... 
probably would wind up in tech news once people notice the breakage.


WebKitGTK can be updated because we maintain stable API/ABI.


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

Re: [webkit-dev] Introducing a minimum ICU version for WebKit




Any objections to uploading a bundled ICU 60 under Source/ThirdParty?

Seems easier than forcing downstreams to work out bundling themselves. 
Most major distros will just stop providing WebKit security updates if 
we don't bundle it for them. E.g. this is sure to kill Ubuntu's current 
long streak of providing our updates to Ubuntu 16.04.



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

Re: [webkit-dev] Introducing a minimum ICU version for WebKit





On Thu, Apr 9, 2020 at 7:08 pm, "Olmstead, Don"  
wrote:

Hi Michael,

There are a couple problems with checking in a version of ICU.

* Other libraries used by WebKit have dependencies on ICU. For our 
ports harfbuzz, libxml2, libxslt, libpsl and CFlite all require ICU.


You're right, it's a bad idea.

* ICU doesn't come with a CMake build system and its non-trivial to 
make one. We've largely used this 
https://github.com/LibCMaker/ICU_CMake_Files to handle building ICU 
but its use is also why ICU is the library we aren't able to update 
on a regular cadence.


Another good point. Hadn't thought that through far enough.

* We aren't terribly good with updating things in ThirdParty. 
Sometimes this is because there aren't releases, see gtest. Others 
because they don't actually have releases, see ANGLE. On top of that 
there might be local modifications to make things work within WebKit.


Of course, bundling things in ThirdParty is an absolute last resort. 
But when using system packages is no longer possible, what else to do? 
I have to support WebKit on RHEL 7, which has ICU 50. Mike from SUSE is 
trying to support SLE 12, which has ICU 52. You can see it doesn't add 
up. :)


But I didn't object to the ICU 60 proposal because (a) our dependency 
policy allows cutting off distros older than Ubuntu 18.04 and Debian 
Buster, and (b) I figured we would just bundle it. Instead, a better 
approach is probably to come up with downstream patches to revert all 
the changes that require ICU 60 and maintain them as long as we can. 
Same goes for CMake, but it's going to get a lot harder as WebKit usees 
more and more new CMake features. At some point we'll probably need to 
try bundling a custom CMake, since eventually that will be easier than 
patching WebKit to use ancient CMake.


Could you possibly give some overview of how WebKit is packaged by 
Linux distributions? I would have thought they would use 
flatpack/jhbuild to get the dependencies that the WPE/GTK ports are 
using especially if those dependencies have their own set of bug and 
security fixes. My experience with Linux is minimal so some context 
here would be appreciated.


No, distros build against their own system packages.

JHBuild is a developer tool. And flatpak is cool, but not used to build 
distro packages. Fedora is experimenting with distributing applications 
using flatpak, but you can't distribute system libraries that way.


For our ports we use vcpkg to build and manage dependencies. We host 
it at https://github.com/WebKitForWindows/WebKitRequirements and have 
an internal fork for PlayStation. I'm guessing it's probably similar 
to flatpack/jhbuild in terms of functionality but in our case we just 
use GitHub releases to have binaries ready.


Perhaps there are better ways for us to approach the requirements 
that would be beneficial to all ports?


I don't think there's really anything to do other than to decide how 
many old distros we're willing to cut off of updates. Currently the 
dependencies policy protects distros for three years. To continue 
supporting Ubuntu 16.04 (which reaches EOL in April 2021), it would 
need to be extended to five years. Probably not many developers would 
be very happy with that at all. But Ubuntu have a five-year lifecycle, 
so it's tough beans for WebKit users if we drop support before that 
time. RHEL and SLE have 10 and 12-year lifecycles, respectively... 
nobody is going to propose supporting that upstream, we just have to 
either figure out how to deal with it or cut off updates eventually 
once it becomes too hard to build.


I'd support extending our dependencies policy from three years up to 
five years... only problem is, five years makes it really hard to use 
new C++ features, and we like those. :( Anyway, with the current 
dependencies policy, ICU 60 is allowed. We'll just have to figure out 
how to deal with it downstream.


Michael


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

Re: [webkit-dev] webkitgtk and bubblewrap help needed

2020-04-28 Thread Michael Catanzaro

On Mon, Apr 27, 2020 at 11:22 pm, Jack Hill  
wrote:

Can this problem be worked-around in WebKitGTK?


Looks like WebKit should call realpath() for each path it passes to 
bwrap. Annoying, but certainly doable. Want to report a bug for it on 
WebKit Bugzilla?



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

Re: [webkit-dev] Position on User-Agent Client Hints

2020-05-07 Thread Michael Catanzaro

My personal $0.02: I'm mildly supportive of this spec. It's certainly 
an improvement on existing HTTP user agent headers. I appreciate that 
you worked to incorporate feedback into the spec and considered the 
concerns of small browsers.


Is it going to solve all the problems caused by user agent headers? No. 
If WebKit implements the spec, we're surely going to eventually need a 
quirks list for user agent client hints to decide which websites to lie 
to, just like we already have quirks for the user agent header. And as 
long as Chrome sends a user agent header that includes the string 
"Chrome", it's unlikely we'll be able to get rid of the existing quirks 
list. But I think client hints will probably reduce the amount of 
websites that *accidentally* break WebKit, by replacing wild west UA 
header parsing with well-defined APIs, and adding some GREASE for good 
measure. The promise of freezing Chrome's UA header sounds nice, as it 
makes quirks easier to maintain. And being able to ration entropy by 
revealing details about the platform on an active rather than passive 
basis is quite appealing.


The spec attracted some misplaced concern about negative impact to 
small browsers, which I've rebutted in [1]. I'm not quite so 
enthusiastic about this spec as I was initially, especially after I was 
convinced that the GREASE is never going to be enough to remove our 
quirks list, but it's certainly not going to *hurt* small browsers.


This spec has received some pretty harsh criticism from the user 
tracking industry (some call it the "ad industry"). Not historically a 
friend of WebKit, so sounds good to me. ;)


One concern I haven't mentioned elsewhere is that frozen UA header 
might encourage deeper levels of fingerprinting than are currently 
used, e.g. for ad fraud prevention. caddy has started blocking 
WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. 
If techniques like that take off as a result of this, that could 
potentially backfire on us quite badly. But websites could choose to do 
such things today anyway, client hints or no, and if so, the solution 
will be for us to just try even harder to look more like Chrome.


Seems like a net positive overall. I don't work for Apple and can't say 
whether it might be implemented by WebKit.


Michael

[1] 
https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002

[2] https://mitm.watch/


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

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Michael Catanzaro

On Wed, Oct 7, 2020 at 4:17 am, Konstantin Tokarev  
wrote:

BTW, could you estimate how many of users which have provided
meaningful bug reports were directed to bugs.webkit.org but never 
made it?


A lot. I'd say maybe about half make it upstream. That's OK. We don't 
have time to fix everything, after all, and it doesn't make sense to 
focus on bug reports where we cannot easily interact with the reporter.



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

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Michael Catanzaro




I suppose what I'm describing is Konstantin's Workflow 2, which is 
overwhelmingly popular.


On Tue, Oct 13, 2020 at 2:19 pm, Ryosuke Niwa  wrote:

Not squashing only helps if each commit can stand on its own. At that
point, I'd suggest such a sequence of commits be made into multiple
PRs instead of multiple commits in a single PR, each of which requires
a separate code review.


Commits are certainly expected to stand on their own (not introduce 
defects). If they can't, then they should be combined into another 
commit! Hence, we should not approve MRs if the MR contains commits 
that fail to meet our usual standards. Such commits should just fail 
code review. (But if you aren't willing to review MRs commit-by-commit, 
then indeed you'll never notice when such problems exist.)


If I have to open a separate MR for each change, though, I'm going to 
wind up combining multiple lightly-related changes into one big commit, 
because a new MR for every tiny cleanup I want to make requires effort. 
Such commits may be common in WebKit, but they would fail code review 
in most other open source projects. E.g. in 
https://trac.webkit.org/changeset/268394/webkit I snuck in a drive-by 
one-line fix that's unrelated to the rest of the commit. I would rarely 
dare to do that outside WebKit, knowing it would probably fail review, 
but we do it commonly in WebKit because we discourage multiple patches 
per bug and don't want to create new bugs for every small cleanup.



This to me is a show stopper. When I'm trying to bisect an issue,
etc..., the biggest obstacle I face is any intermediate revisions
where builds are broken or otherwise non-functional. I don't think we
should let anyone merge a commit into the main branch unless the
commit meets the same standards as a regular Bugzilla patch we land
today.


I agree. But I would say that a MR with such history should fail 
review, and be rewritten to not suffer from these problems.



I disagree. Detailed descriptions and function-level change logs are
exactly what I use to dig up all the code history and figure out
what's causing the bug and how to fix in numerous occasions. Not
having that would be a massive regression.

- R. Niwa


Detailed descriptions are very important. I don't think function-level 
changelogs are; documenting changes in individual functions is 
generally busywork to say what you can plainly see by just looking at 
the diff. I'll submit 
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1686/commits as an 
example of my preferred commit granularity and verbosity. (We can 
pretend it is not currently failing CI. ;) Here the commits are 
lightly-related and could perhaps be split into multiple MRs, but 
honestly that becomes annoying and unwieldy, especially as some of the 
commits depend on each other and need to land in a particular order, 
and since creating new branches and MRs (or bugs on Bugzilla) for each 
commit becomes annoying. So it's nicer to do it all in one. One of 
these commits actually makes changes that are undone by a subsequent 
commit, and is primarily there just so that I could write a commit 
message about it and show the history in two steps rather than one! 
History like that would be lost in Konstantin's Workflow 1. I don't 
think ChangeLog-style function-level detail would be helpful in any of 
them; in WebKit, I usually ignore that anyway. But all of the commits 
do have a detailed commit message, except for "fix typo" and "fix 
whitespace" (can't expect an essay for those).


Regarding line-by-line commit review... well, it would be nice to have, 
of course.  But I don't think it's as important as you suggest. 
Problems with commit messages are usually general problems with the 
entire commit message rather than problems with a specific line of the 
commit message. An exception is typos. It is harder to point out typos 
without a line-by-line review tool. But still, it's not too hard to 
tell somebody to fix a typo without being able to highlight the right 
line.


Michael


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

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Michael Catanzaro

On Tue, Oct 13, 2020 at 12:32 pm, Maciej Stachowiak  
wrote:
I’m assuming your objection is to regular merges, but how do you 
feel about squash merges? Or do you think all PRs should be landed by 
rebasing?


If we want a linear history (we do), all PRs ultimately have to land as 
fast-forward merges, one way or the other. I think rebasing is the 
simplest way to accomplish that, but squashes work too if all your 
changes are sufficiently self-contained to land as one commit.


I suggest leaving this up to the discretion of the developer and 
reviewer rather than mandating one way or the other, because there are 
advantages and disadvantages to both approaches. If your local commit 
history is a mess, sometimes squashing it all into one commit is an 
easy way to make it acceptable for upstream. If you hate rewriting 
history to make it look good, and your MR isn't too huge, a squash 
might be appropriate. But more often than not, I'd say that would 
result in a worse commit history.


My own preference would be to require squash merge, because it keeps 
the history simple for the main branch, but does not risk putting 
intermediate revisions which may work or even build on the main 
branch.


The disadvantage is that if you squash before merging, you encourage 
fewer, bigger commits that might be harder to read and potentially much 
less fun to discover at the end of a bisect. E.g. consider a very 
common case: developer wants to fix a handful of separate but related 
bugs in a particular section of code. We could land all the fixes in 
one huge commit, but that's inevitably going to be harder to read, 
harder to deal with if it introduces a regression, and will certainly 
have a more confusing commit message (either because it gives less 
detail about the changes, or because it's very long describing multiple 
related changes that could have been separate commits). We could split 
it up into different MRs for the different commits, but that becomes 
annoying when the commits are related, and hard to keep the different 
MRs in order. So I don't normally squash (except when committing small 
fixup commits via the web UI), because the disadvantages generally 
outweigh the benefits.


On the other hand, if you don't squash, it's indeed possible that your 
commit history might be messy, e.g. intermediate commits might break 
tests fixed by subsequent commits, or intermediate commits might not 
build at all. Squashing before merging does eliminate those risks, but 
I recommend code review instead: commit history and style is subject to 
review just like code changes are. Sometimes I see a merge request with 
a messy commit history that just begs for two or more commits to be 
squashed together. (This is common for students new to open source. 
WebKit does not have this problem currently.) Sometimes I see the 
opposite, where too many changes are bundled into one big commit. (This 
is more common in WebKit, since we normally try to have one patch per 
bug, and splitting changes into multiple bugs is inconvenient.) But 
usually the developer submitting a MR has found a good balance between 
the two extremes. Ultimately, what's most important is landing a clean 
commit history with reviewable commits. Again, the scope of commits is 
subject to review just like code changes are.


I agree that we don't want to merge WIP commits of any form, and 
reviewers should complain if these appear in a MR. E.g. if making an 
API change that requires updates in 200 files, we surely want them all 
updated in one commit, because we don't want broken intermediate 
commits on master that would break bisections. So sometimes huge 
commits are unavoidable. Similarly, if an intermediate commit is known 
to break a test, that's not good either because it could mess up 
bisects. (I don't think we necessarily need to run tests on every 
intermediate commit -- that might be too much for our infrastructure -- 
but we could if desired.) What we don't want is to wind up merging 
low-quality stream-of-consciousness style commits that looks like they 
were committed in the order the code was written. I think that's what 
you're trying to avoid by suggesting squashes. Instead, I suggest 
developers should aggressively use 'git add -p' and 'git rebase -i' to 
selectively commit, rewrite, and reorder history to look good before 
opening the MR. This isn't optional for most open source projects: if 
you propose an MR with ugly commit history, it won't be merged until 
fixed. For a typical MR of moderate complexity, I'll use 'git rebase 
-i' at least a couple times before the history is clean enough for a 
MR, and to make fixup commits disappear into the most-appropriate 
commit in the sequence.


Regarding commit messages, I don't understand why there's any 
expectation that they need to be checked into files in order to be 
detailed and complete. If a commit message doesn't adequately describe 
what it's fixing, then the reviewer should open a

Re: [webkit-dev] WebKit Transition to Git

2020-10-05 Thread Michael Catanzaro

On Mon, Oct 5, 2020 at 8:40 am, Jonathan Bedard  
wrote:
That's one solution, but even that is somewhat insufficient because 
we don’t want to give someone access to every security issue just 
to give access to a single one. One of the solutions we’ve 
discussed is to migrate bugs component by component, the security 
component may stay on bugzilla indefinitely.


Can you grant access to a single issue by CCing the desired user to the 
issue? I expect that would work (not tested).



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

Re: [webkit-dev] WebKit Transition to Git

2020-10-06 Thread Michael Catanzaro

On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev
wrote:

1. Sub-par support for linking issues to each other

Traditional bug tracking systems (like Bugzilla or JIRA) have support
of "related" or "linked" issues. Most important relations are

* A depends on B (B blocks A) - blockers and umbrella issues
* B is duplicate of A
* A and B are related in other unspecified way

GitHub does have duplicates btw, but the syntax is completely different
from GitLab so I can never remember how it's done. It's not exposed in
the UI. In GitLab it's easy: /duplicate #245 to mark a bug as duplicate
of issue #245. (You can have cross-repo duplicates too, and I think
even cross-*project* duplicates. This is very important for GNOME, but
not for WebKit since WebKit is just one huge repo.)

I found instructions for GitHub here:
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests#marking-duplicates

* There is no easily visible list of relations: if you are not
closely following all activity on A, to find all issues related to it
you have to browse through all its (pseudo-)comments, which in some
cases might be long.
* There is no *stateful* list of relations: if A was believed to have
common source with B, but then it was discovered they are not
related, you cannot delete relationship between A and B because there
is no relationship, just a set of comments.

In my experience, this isn't really a *huge* problem. Umbrella issues
work well enough to track relationship between bugs, as do milestones,
and you can use whichever you prefer. I admit it is not nearly as nice
as Depends/Blocks from Bugzilla, though. But I think it should be good
enough for us.

* "#" is not a safe reference format. Sometimes users'
comments may have other data in "#" format with a different
meaning than references to GitHub issues. For example, may the force
be with you if someone pastes gdb or lldb backtrace into comment
without escaping it into markdown raw text block (```). Also, GitHub
parses mentions in git commit messages, so care must be taken to
avoid any occurrences of "#" with a meaning different from
reference to issue number.

Yeah this is unfortunate and also guaranteed to happen. The first
several dozen issues are going to be spammed with references to other
bugs all over the place.

[2] For some reason they have shared numbering, which means sometimes
you may not know what kind of reference is in front of you until you
look up its URL or navigate

This is silly too (and not a problem on GitLab, which uses # for issues
and ! for merge requests). But although I agree it is a defect, is it
really a huge problem? Probably not.

Also, on test cases. You probably like this feature of Bugzilla when
you can attach self-contained HTML file to the issue and then simply
open it by URL in any browser including your build of WebKit to try
it out. Forget this - GitHub simply forbids HTML or JS attachments
(without wrapping them in archive):

"We don’t support that file type. with a GIF, JPEG, JPG, PNG,
DOCX, GZ, LOG, PDF, PPTX, TXT, XLSX or ZIP."

And yes, take care not to use tar.xz or tar.bz2 or any other
unapproved archive type.

OK, now you've convinced me... this is bad. :P I forgot about this
problem because GitLab does not have any such restrictions on
attachments. It's very frustrating to have to say "I added a .txt file
extension so I could upload this to GitHub. Please remove the file
extension after you have downloaded the file before you use it." I
would say this is strongest argument I've seen against GitHub. Silly
problem to have tbh.

I'll just add that GitLab has become *really* popular for Linux-related
projects. I have to regularly work with GNOME GitLab, freedesktop
GitLab, and gitlab.com. Fedora and CentOS are both switching to GitLab
too, so soon that will be five different public GitLab instances that I
have to switch between regularly, and that's limited to only the public
instances. Then there are also many major communities I don't work with
that are also using GitLab (KDE, Debian, Purism). It's reached the
point where unless you only work on Linux kernel itself, you probably
spend a lot of time on one GitLab or another. It should be considered
alongside GitHub as an option, especially if we're concerned about
GitHub-specific problems.

And when issues are triaged, they can be resubmitted to WebKit
tracker by qualified person if they are really relevant.

In practice, I don't think it's a good idea because (a) moving bugs
upstream takes a lot of time, (b) it's quite often important to have
the original reporter CCed on the issue and able to comment. I receive
tons of WebKit bugs in the Epiphany bugtracker, and while a few years
ago I might have forwarded reports upstream myself, nowadays I only
provide

Re: [webkit-dev] WebKit Transition to Git

2020-10-06 Thread Michael Catanzaro

On Wed, Oct 7, 2020 at 2:22 am, Tetsuharu OHZEKI 
 wrote:

If we move to GitHub Issue, compared to bugzilla, that does not have
"component watching".
(I don't know the case of GitLab's Issue)
We only can watch all issues or not for the repository.


Oh dear. I had assumed that you could easily subscribe to particular 
labels (as you can in GitLab) but, poking around in GitHub's UI, I 
indeed don't see any way to do that. :/


That's no good. E.g. multimedia developers expect to be able to 
subscribe only to multimedia bugs, WebKitGTK developers will want to 
watch only GTK bugs, etc.


Michael


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

Re: [webkit-dev] Question: referrerpolicy in Safari

2020-09-23 Thread Michael Catanzaro




On Wed, Sep 23, 2020 at 1:50 pm, Dominic Farolino 
 wrote:
I haven't dug too deep here, but just going to post this in case it 
answers your question and saves you some time. As documented here, it 
appears that Safari is starting to not honor the `referrerpolicy` 
attribute on HTML elements where it would override the referrer 
policy redaction that their cross-site tracking work has performed, 
or at least in cases where it would expose more information than what 
was intended by the cross-site tracking protection. That may be an 
oversimplification, (I trust someone from WebKit can clarify), but it 
may explain the behavior you are seeing.


That probably explains case 1. There's some documentation of this at 
https://webkit.org/tracking-prevention/. The actual URLs matter here. 
With https://site-one.example/path/foo and https://site-two.example/, 
the top privately-controlled domains are different (site-one.example 
vs. site-two.example) so the referrer will be downgraded to its origin. 
But say you were instead testing https://site-one.example.com/path/foo 
and https://site-two.example.com/, then the top privately-controlled 
domain in both cases is example.com, and there's no forced downgrade.


That doesn't explain what's going on in case 2 or case 3, though. 
Smells like bugs?


Michael


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

Re: [webkit-dev] WebKit Transition to Git


On Fri, Oct 2, 2020 at 09:43, Jonathan Bedard  wrote:
The biggest blocker we are aware of is managing security bugs, since 
the security advisory system used by GitHub is essentially the 
opposite of how WebKit security bugs work. Moving to GitHub Issues, 
if it happens, will be the last part of this transition, and we are 
interested in soliciting feedback from our contributors on what the 
WebKit project’s integration with GitHub Issues should look like.


I don't think we need much integration to use the issue tracker? Once 
we migrate existing bugs from WebKit Bugzilla, we can use it as we 
would any other issue tracker? Why would it require integration?


We might need to use a separate repository with more limited 
permissions to handle security reports. At least in GitLab, all project 
developers (committers) have access to all confidential issues. I'm not 
sure about GitHub, but I assume it would be the same.


What will require integration is pull request merges. If we want to 
maintain linear version history, we will want a merge bot. On GNOME 
GitLab, we have a large number of smaller projects and it's we don't 
need them, but for a one huge project like WebKit there will be too 
many conflicts otherwise, because every commit going into the main 
branch will require all other pull requests to be rebased. A merge bot 
-- e.g. [1] -- will handle that for us. (Not sure what merge bots are 
common on GitHub. )


Michael

[1] https://gitlab.com/fsdk-marge-bot


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

Re: [webkit-dev] WebKit Transition to Git


On Fri, Oct 2, 2020 at 13:48, Ken Russell  wrote:
Github's code review UI has a couple of feature gaps in my opinion. 
It's difficult to look at earlier versions of the pull request, in 
particular to verify that issues found during code review have been 
fixed. I remember it also being difficult to figure out whether all 
comments on earlier versions have been addressed.


I'm not familiar with reviews on GitHub. I just want to add that GitLab 
reviews are great and have none of these problems. It's very easy to 
view older versions of merge requests and compare the differences 
between arbitrary revisions of the merge request. (That's often 
important when reviewing small changes to a large merge request.) Every 
discussion thread is clearly marked as either resolved (green!) or 
unresolved, and you can (and should) configure GitLab to block merges 
until all discussions are resolved. (I would be disappointed if GitHub 
doesn't have the same convenience features, as this helps prevent 
mistakes from being forgotten.)


I realize that Gerrit might not integrate at all with hosting the 
repo on Github, but has any thought been given to this aspect of the 
transition?


That sounds like it would be a significant barrier to contribution, and 
frankly defeat the point of switching. If we have serious concerns with 
GitHub's code review functionality (which, again, I'm not familiar 
with), then we should just use GitLab and have everything in one place. 
(GitLab accepts GitHub logins via OAuth, both on gitlab.com and 
self-hosted instances, so the barrier to contributing remains low 
either way.)


Michael


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

Re: [webkit-dev] WebKit Transition to Git

On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  
wrote:

Would you also consider preventing merge commits in order to keep a
clean mainline branch?


Big +1 to blocking merge commits. Merge commits in a huge project like 
WebKit would make commit archaeology very frustrating. (I assume this 
is implied by the monotonic commit identifiers proposal, but it doesn't 
exactly say that.)


I'm sure transition to git and GitHub should go well. I would have 
selected GitLab myself -- it's nicer and also overwhelmingly popular -- 
but whatever. (Does GitHub have merge request approvals? Replicating 
our reviewer/owner permissions with GitLab merge request approvals 
would be easy.)


One downside is that using github.com might actually make it *too* easy 
to spam us with low-quality issue reports and merge requests. We've 
historically been pretty bad at maintaining a clean issue tracker -- 
the quantity of untriaged issues on Bugzilla is very high -- and GitHub 
will make this worse. That's not an issue with the GitHub platform, 
though. Just something to stay on top of.


Michael


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

[webkit-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)