Haikuwebkits new Home

Development OS
1

Hello there,
I am quite happy with all the interest in Webkit recently.

And I am happy to announce that Haikuwebkit will migrate to codeberg.
The new URL will be: https://codeberg.org/haiku/haikuwebkit

Now, with a new home there are some changes.
The first big change is that there is no more forking and PRing, Instead contributors are expected to use the agit workflow. For those of us already using Gerrit this should be right at home.
But the TL;DR is: No more “forking”, instead push your changes to a special target of the repo you pulled it from.

Documentation on this flow can be found here: AGit Workflow Usage | Forgejo – Beyond coding. We forge.

The reason for this is quite straigforward, Haikuwebkit is big, and while we do have a storage quote exemption we don’t want to force severall huge repos onto codeberg. Unlike github codeberg does not sneakily treat all forks as the same repo, but treats them completely seperately, hence there is a real disk cost involved.

If you already have the haikuwebkit repository from github there is no need to re-clone it!

The url for the “origin” (the default push/pull target) can simply be updated.
If you want to use https cloning for example you can use this:

git remote set-url origin https://codeberg.org/haiku/haikuwebkit

Or alternatively git remote can be used to add a second upstream.

The repository is hosted under the “Haiku” Organization, If you are a haiku developer waddlesplash or
kallisti5 can invite you, otherwise there is no need to worrry about this.

Pushing a change for review, for example, is done like this:

git push origin HEAD:refs/for/haiku -o topic="stop-crash-with-contextmenu"

If there are questions about the new home or workflow, feel free to ask them here!

17 Likes
5

Does it means the haiku-webkit2 still exists ?

1 Like
6

Nothing changed with the branches, all have been migrated.

1 Like
7

Ok thanks. Another question : once the origin has been updated as indicated (and no more upstream repo needed if I understand correclty), is there any rights to have to be able to push a change ?

8

You can still create pull requests as usual if you don’t have commit rights to the repository,it only works more direct now.
Rather than forking the repository,pushing to your fork and creating a pull request,you push to the branch HEAD:refs/for/haiku of the origin repository directly and that automatically creates a pull request where your change is reviewed.
It works identical to Gerrit.

9

This is the new upstream repo, it is required instead of the github one.

To push a commit “as a PR” with the agit workflow requires no special permissions, but pushing to the repo directly to the main branch requires permissions (and those won’t be given to people without commit access to Haiku :slight_smile: )

10

Ok I think I got it.

I’m currently on the haiku-webkit2 branch, if it might clarify the process to move from github to codeberg, I’ve documented the below commands (no more fork repo, so need to remove the upstream):

git remote remove upstream
git remote set-url origin https://codeberg.org/haiku/haikuwebkit

Then for any fix/enhancement proposal :

git add Source/WebKit/Shared/haiku/XXX.cpp
git commit -m "Haiku: fix executable path using BPathFinder"
git push origin HEAD:refs/for/haiku-webkit2 -o topic="fix-executable-path"

Let me know if it’s in line, I will test this workflow soon I hope :slight_smile:

11

upstream is a remote you added yourself in that case, so there is no need to delete it for other people :slight_smile:

You only need to set the url of the origin, as per your second line. But it looks good otherwise

12

I notice that there is no IRC bot notifcations for pushes to the new repo. Would be nice to set that up, does Codeberg support it in some way? (In github we use some web hooks that push things to a 3rd party bot, we can probably set up something similar if direct sneding to IRC isn’t supported).

13

Yes, this is possible in the same way with forgejo: Webhooks | Forgejo – Beyond coding. We forge.

I don’t really know how our current webhook→irc stuff works (i.e which server wants to be pinged) otherwise I would have already set that up. I suspect @kallisti5 has that info and can help me set it up :slight_smile:

They actually have dedicated events for severall chat services already… Of course no XMPP and IRC :smiley:

14

EDIT : I’ve created a CodeBerg account and setup it on my machine.

Now I have the below error :

git push origin HEAD:refs/for/haiku-webkit2 -o topic=“Fix MiniBrowser crash when quitting”
Username for ‘``https://codeberg.org``’: DigitalBox98
Password for ‘``https://DigitalBox98@codeberg.org``’:
Enumerating objects: 28318, done.
Counting objects: 100% (22774/22774), done.
Delta compression using up to 4 threads
Compressing objects: 100% (8280/8280), done.
Writing objects: 100% (16982/16982), 19.09 MiB | 1.60 MiB/s, done.
Total 16982 (delta 14243), reused 10632 (delta 8550), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (14243/14243), completed with 4059 local objects.
remote: Checking connectivity: 714, done.
remote: error: cannot find hook ‘proc-receive’
To haiku/haikuwebkit: Home of the Haikuwebkit project; We accept contributions with the agit workflow. https://forgejo.org/docs/latest/user/agit-support/ - Codeberg.org
! [remote rejected] HEAD → refs/for/haiku-webkit2 (fail to run proc-receive hook)
error: failed to push some refs to ‘``https://codeberg.org/haiku/haikuwebkit``’

15

Hmm, I’m not sure if that is a bug or maybe an undocumented dependency. I will ask the codeberg folks later today :slight_smile: (unfortunately they are only on matrix, which makes contacting them extremely cumbersome)

16

The issue should be resolved now, the hook is back on the codeberg side, so you should be able to push your commit for review! :smiley:

1 Like
17

The first two commits from @DigitalBox Got merged, hooray. It seems the new haikuwebkit home works :smiley:

6 Likes
18

Yes :slight_smile: I’m just adjusting on my side what is the best workflow for submitting a change. For the moment I will only do it on a sequential approach (ie only work on a fix when the last one is merged) because working on parallel fixes was a nightmare for me :joy:

The second point I need to check also is how to avoid when possible that a simple fix launch the whole compilation again, as it takes a long time to rebuild all. I have not yet identify the reason why changing only MiniBrowser sources rebuild the whole WebKit.

I will pay attention to these points for my next change proposal (fix back/forward), I hope it should be more smooth.

19

The compilation should not restart “entirely”. One problem with webkit is the unified builds, this will cause unrelated sections to be rebuild even if you only work on one. The other is wether you used ninja or the build script directly.

You should also take care to have installed ccache before configuring the build, it will for the same inputs cache the result, and therefore be able to skip a lot of re-compilation that did not need to be done.

Another option for speeding up the build is using LLVM/Clang instead of gcc, especially using the llvm linker worked better iirc.

… All stuff we should write into the Readme :frowning:

1 Like
JavasScriptCore integration into webkit
20

Ok thanks! now I understood as I have followed just the README which is working fine, but which is not the « optimized « way to work with this monster to compile

Maybe the next fix will be to fix the README then :stuck_out_tongue:

21

Yeah, a lot of stuff also changed. and especially @madmax gave me the knowledge of a lot of the “tricks” here :wink:

2 Likes
22

Moving forward : the popup menu (right click) is still not implemented, but no more crash now :slight_smile:

3 Likes