3 ms·
This gets more complex when you have, for example, a volatile open source codebase as an upstream. At work. we regularly merge upstream FreeBSD into our codeba
by drewg123 8y ago
This gets more complex when you have, for example, a volatile open source codebase as an upstream.
At work. we regularly merge upstream FreeBSD into our codebase, and run a suite of tests to make sure that we have not introduced a regression in performance or functionality. These tests take days to run, and roughly another day to analyze.
What causes a cherry pick is if we realize late in our release process that we're suffering from a bug that was fixed upstream (or that we can fix upstream). Since we're late in the release process, we don't want to take a full sync to the tip of the upstream master and consume potentially unstable changes, as that will mean re-running all our tests and resetting the clock on the release. So we cherry pick the fix (sometimes after committing it upstream ourselves).
- danieldk 8y agoOut of curiosity. What are you working on? A derivative of FreeBSD?
- drewg123 8y agoThe Netflix CDN. We run a slightly modified version of FreeBSD.
- deleted 8y ago[deleted]
- peterwwillis 8y agoIs this just the kernel, or the OS as a whole? This is probably a redundant comment, but maintaining a fork of a vendored product kind of defeats the purpose of using the vendored product. If at all possible I would recommend either to use the vanilla release, or fork it once and stop integrating. If you were shipping your custom FreeBSD to customers, and they were relying on it being FreeBSD plus your changes, I can see integration providing significant value. But since it's for a CDN, it's probably only being used by your team.
- mariusmg 8y agoAre you working on the PS4 OS ?
- deleted 8y ago[deleted]