[geofft]

What I'd like to see is a Firefox (and Chromium) fork with

- automatic builds and uploads via GitHub/GitLab CI (or similar) from a well-commented build script

- all the knobs for reproducible builds set up, so anyone can fork the repo, run the CI themselves, and see that it's bit-for-bit the same thing

- an automatic merge or rebase of the latest stable release tag, and the result of that merge being plugged into automatic updates

- an automatic merge or rebase of the latest beta tag (or even nightly), and some form of alerting if the build fails

- perhaps some Selenium + Wireshark automation to see what requests happen and make sure there are no unexpected ones

And, actually, it seems like LibreWolf is on the way there. https://gitlab.com/librewolf-community/browser/common has a decently-well-commented build script that grabs the latest tarball from Mozilla and builds on top of it and even supports building on nightly, and their documentation (https://librewolf-community.gitlab.io/docs/) mentions that as well. But I don't see where it is run / who runs it, and what they do if the build fails.

(Honestly it seems like setting up the release automation and alerting is a substantial project in itself.)

[alexmcc81]

I see Brave are interested [1] in reproducible builds but it's not implemented yet. [2] I'm not sure if their CI artifacts are public or not.

[1] https://brave.com/building-brave/ [2] https://github.com/brave/brave-browser/issues/5830

[mdaniel]

This is relevant to my interests (less the reproducible builds part, but very much the "well commented CI script" part), and for a frame of reference I have successfully built the last couple of brave tags because I'm persistent that way. But I haven't put it in my CI yet because they appear to clone *the whole chromium* repo courtesy of depot_tools & gclient, making the caching story very bad as that git repo is twenty two gigs (not the checkout, mind you, I mean the git repo)

Plus, the build takes several hours on my Ubuntu machine, so unknown what the CI job timeout is or how beefy the runners need to be in order to not OOM a monster C++ linker

I want to be careful with this commentary, because it's just my opinion as an outsider, and ultimately it's their project. But I struggle mightily with the decision tree that lead one to have a home grown build system written in npm that shells out to depot_tools, gclient, a bunch of manual git clones (although there are some git submodules, too), then a ... fascinating ... manual patching system layered on top of it all. I'm glad it works for them, but it makes wading in by the casual user incredibly hard.

Compare that to mozbuild (and its new "mach" friend) that as very best I can tell is python all the way down and since their CI system is also open source, one can very easily crib enough config files to build it locally

[dblohm7]

A lot of those forks don't even bother with CI: Some of them, one of their first commits is to remove all the tests.