This could be useful in many scenarios. Linux distros’ package patches, Rust’s fork of LLVM, ungoogled-chromium, Linux hardware forks (though you should upstream!)…
Today these tend to involve someone manually rebasing/merging, and as such only update upon major releases.
Conversation
Replying to
Talk with maybe? I don’t know how he manages his Android fork but it’s pretty effective.
1
1
There is a fair bit of scripting being used but the core of our approach is keeping everything cleanly rebased and obsessively cleaning up / minimizing / reviewing our patch sets to the upstream repositories. Also, tricking upstream into doing our work for us tends to work well.
1
1
2
Figuring out how to file issues relevant to us upstream as security bugs or enterprise support bugs is an important art form. You can see we have a bunch of scripts like github.com/GrapheneOS/scr and github.com/GrapheneOS/scr but I have a lot that's not cleaned up to be published.
1
We'd like to be trying to land a lot of stuff upstream again but we've had a lot to deal with recently. Focusing on development at all has been difficult. Our changes to Chromium aren't as substantial and we feel most could realistically be landed upstream as build configuration.
1
Chromium is used by a bunch of projects including major browsers like Microsoft Edge. The upstream open source project should really be a lot more vendor neutral in the first place. Should be easier to change defaults and services should be optional / have configurable provider.
1
I wouldn't want to deal with CI applying our Chromium patches repeatedly as it goes through development. If we had more resources, we'd rather start porting / testing patches to a Beta release for an upcoming major release and have most ready for the upcoming Stable release.
1
1
AOSP is a lot harder because it's developed internally and we unfortunately do not currently have early access to the major releases. Each major release gets 3 years of security updates but we consider it extremely important to port to the yearly major release within a few weeks.
1
1
They often back out changes or revise something a lot so I just don't want to deal with it as it goes through development. Better to start on the Beta of a certain release as it's approaching the Stable release and port to it a week or so from the Stable release so it's ready.
1
Chromium 89 is in Beta right now. It would make sense to port to Chromium 89 approximately 1 week before it's released and deal with the bulk of the work during that week. Then, when the Stable release comes out with the security patches, it's all ready. We did this for 87/88.
1
For AOSP, we'd ideally have access to the preview of the new major release for partners and we could start porting to it about a month prior to the stable release. That way, instead of simply doing the security update for past branch + starting porting we could have it all ready.
AOSP is more aligned with what we want downstream. It already avoids using proprietary Google services. It only uses them as the provider for some open standard services.
Chromium is *currently* far different. There's tons that needs to be removed. Ideally it'd change upstream.