2023 Getting into web engine contributing
- Date: 7th Jun 2023
- Issue: https://github.com/Igalia/webengineshackfest/issues/20
CanadaHonk: (presents slides)
Emilio: I'm surprised to see you say that MozillaBuild is easy.
Andreu: You mentioned the github issue for WebKit, that was a really recent change. I wonder if there are people in the room willing to comment about that. I haven't worked too much about that.
Pablo: What is your interest in this topic?
Andreu: In the past you had to attach patch on Bugzilla to contribute to WebKit, which is a different workflow than GitHub.
Pablo: you mean it's getting easier to contribute? Some people commit more but indeed, that's also different for dealing with the patch in Bugzilla (discussio, review...) You have a branch for your merge request and that is easier. I think that's the best improvement, at least for me. Of course you have a more modern UI than bugzilla. It was definitely a change for the better, but not that much of a big change.
Emilio: Do you still use changelogs? Rather than writing a decent commit message, you have a huge changelog.
Pablo: Yes, there is are longer changelogs and merge conflicts to deal with. Someone else?
CanadaHonk: I will work on fixing a WPT. I have the Gecko source checkout. Gecko has failing WPT where SVG scripts are sometimes not run when needed or run when not needed. We will be fixing it and copying some updates. They have this code for getting the script type for the script DOM element, but not for the SVG script. If we copy them to the SVG, it should now work the same. (presents patch) We run mach build.
Andreu: I was wondering how you decided to get involved in fixing bugs. As a comparison, I spend a lot of time reading specs until finally decided to fix a Gecko bug that annoyed me. It wasn't easy to find where the relevant code was, so I set myself an afternoon to fix it, and I would give up if I hadn't found out after that. Was that similar for you? How do you find things in the code?
CanadaHonk: In searchfox, if you search for a function you can see every usage in the code. Chromium has someting similar as well. It's useful. Some bugs will link to the relevant source file.
CanadaHonk: Running mach wpt with the file location.
(Remote participant): What is mach, is that a script?
CanadaHonk: generic script Gecko uses to do anything, building or testing etc
(Remote participant): I just gonna ask if the SVG spec, does it say the same as HTML for the script type?
CanadaHonk: Not sure, but there are failing WPTs. Now, with the fix built, all the tests pass. We now have a lot of unexpected passes, so we need to fix the meta files for WPT and change the expectations. If a test is listed as failing and it starts passing, it
Andreu: to clarify a bit. the idea is to find differences with the things you support or don't support. So if you run the CI and it fails because a test started passing, you want to know that, or know if there are flakes.
CanadaHonk: Right. Just going through the manual process to show what it is.
???: You can generate the meta changes automatically using mach.
CanadaHonk: Now you need to commit the patch to mercurial. With Gecko, for commit messages you mostly paste the bug URL, have a summary of the bug and explain the changes. After this, you can use moz-phab to submit it to Phabricator, which is the platform for patches in Gecko. Once that's done, we have a patch fixing the bug.
Andreu: How did you find phabricator & bugzilla as opposed to gihtub which is what people are used to. Did you find it hard?
CanadaHonk: review interface is useful, you can see inline comments etc... more question?
Philip: All mainstream browsers have good first bugs, where they would be good first bugs if you have ...
CanadaHonk: ... Then I started working on CSS with Infinity and NaN, which is a small feature but has big implications. ...
Thomas: How do you evaluate how easy a bug is? How do you find other easy bugs?
CanadaHonk: I filter WPT tests to see which tests fail in Firefox but not in other browsers, and those are usually small bugs in the Gecko implementation rather than new features. I also look at whether a bug has bugs that block it.
Linus: Now that you have submitted a patch, how do you move forward? Review, landing, how do you know which version of Firefox it will land in.
CanadaHonk: Reviewing is a cycle of reviewers asking for changes and you fixing them, and so on until you agree.
Emilio: Finding reviewers can be touch, especially if you're touching something nobody owns. In Gecko, Phabricator has a reviewer groups feature, where you can tag reviewers for layout, devtools... and you usually get feedback relatively quickly. I try to have my review queue empty. If you know what review group to tag (and you can find them ...), the review processes is not so painful, especially if the fix is uncontroversial.
CanadaHonk: A patch for HTML parsing in Gecko, related to <search> element.
Emilio: If this was urgent, I'd rubber stamp it.
CanadaHonk: The parser is written in Java and compiled to C++
Emilio: The parser code generation is 20 years old.
Tiaan: In Gecko, when your patch lands, you can track in Bugzilla which version it will end up in. There are also places where you can ask for your bug to be listed in release notes, there's MDN... there are a few things you can track after a patch is landed.
CanadaHonk: ...
Emilio: Mozilla and Webkit use bugzilla in different ways. Filing issues is easy, but there's a lot more stuff in release management that you can't do in github. For Webkit, bugzilla isn't the place where the release management happens. Release management depends on each port. But for us all that state lives in bugzilla.
CanadaHonk: There's some massive meta-bugs, like a bug for every single CSS module, with a bunch of things they depend on.
Pablo: For WPE(?) we're not using Github, we have patches that we apply to a version. We still use Trac. It's not a perfect solutin, it was something that worked for a while. Maybe it could be improved in the future.
Emilio: That's fine as long as release management people are happy with that workflow. In bugzilla we have automation, like should a bug be uplifted to an earlier version, to help regressions get fixed? Many times I fix a bug, it's in nightly and I forget. But it's very useful to uplift to an earlier version.
CanadaHonk: There are a lot of regression bugs, like when a test starts failing it files a bug. It keeps tracking whether it has been fixed yet.
Cathie: There's a commit access policy. Can you talk about that?
CanadaHonk: we have a policy with different commit access levels. Level 1 can do try push. Level 2 can land to the tree mozilla-central, Level 3 have commit access to all trees...
Cathie: When can someone apply to level 3?
CanadaHonk: There's no explicit rule, but you need vouchers (people who can say you've done great work on other bugs) and they'll grant access.
Emilio: There's no explicit rule about access after landing X patches. If you behave reasonably, it's easy for other people to vouch for you. It might not be the best process to not have an explicit rule, but it's hard to have a rule. For level 1 access, it's easy, just making sure you're not a bot.
CanadaHonk: I applied for level 1 after ... asked me to apply so I could run tests. I got level 3 last month so I could land patches.
Emilio: Yeah, I always forget to land people's patches.
Philip: I find it hard to get people to land my patches. So I applied to level 3...
Cathie: If we don't have level 3 access, usually you are asking to other people, via matrix etc? do you have recommendations?
CanadaHonk: Yes you can just ping people on matrix and they will land the patch for you.
Emilio: Unless the reviewer doesn't know that you don't have access, we land the patch after it's accepted. Otherwise, pinging someone in Matrix or bugzilla works. There's also a sheriff tag in Phabricator...
Linus: How difficult did you find the transition from git to mercurial?
CanadaHonk: I converted from git to mercurial just from this. I use hg strip to get back from a bug to central. You can use moz-phab patch to checkout a Phabricator patch on your machine, I use it to check it out, fix and submit again.
Emilio: you can also git. when you setup a repo, you turn on a flag to say to use git. It has a script to translate the URL between mercurial and git etc some people are using it. Mercurial has some nice features like interactive commits which are much better than git. In the contributing docs, the first thing you do in non-Windows systems is set up git or mercurial.
Oriol: I tried to have a shallow git checkout of Gecko, and I had problems. Is this supported?
Emilio: Probably not, git and mercurial work differently enough. In order to know the final state of a mercurial file you need to have the full history, which is not the case for git. I suspect this is not important.
Andreu: but gecko and browsers project in general take a long time to have a full checkout, so looking into this would be useful.
Emilio: it's possible that in the future it's supported...
Andreu: How easy or hard did you find specs to follow? For some CSS specs they're not easy to translate into code.
CanadaHonk: (covers a spec PR they worked on)
Philip: congratulates and asks applauses contributing and organizing session after a few months of contribs
Andreu: invites to give feedback if there is anything that can be improved for newcomers to contributing to the web platform
Closing session