Conversation

Has a tool ever been written for automated maintenance+CI of a downstream patch set / fork? In other words, I have an upstream repo, and I want to maintain my own repo which is upstream plus a set of patches. [1/2]

comex

@comex

Feb 23, 2021

But whenever upstream receives a commit, I want automation to try applying the patch set on top of the new commit, and if it works, build+test the result. On failure, notify humans. There should be an explicit, mutable mapping of original commit -> patched commit. [2/2]

comex

@comex

Feb 23, 2021

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.

Replying to

Talk with

maybe? I don’t know how he manages his Android fork but it’s pretty effective.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

6:00 PM · Feb 23, 2021Twitter Web App

Replying to

and

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.

Replying to

and

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.

Show replies