Can't say thank you enough for the massively informative and thorough response!
A few questions:
> You'll need/want to develop a workflow where you fetch the upstream source for a release, apply your patches, and build world, release validation involves checking if your patches are still needed and updating them to still apply if needed.
But doesn't that imply your having to fork FreeBSD just to use it. If so, doesn't that seem excessive for most organizations?
> The other way is to use FreeBSD as a stable base
You're not suggesting to use STABLE, correct. You'd still use RELEASE but rarely update it.
> Can't say thank you enough for the massively informative and thorough response!
No problem. Feel free to reach out via email (address on my profile), if you like. From many interactions in threads, it seems you've got an interest in FreeBSD and Erlang, which matches with my background. Always happy to answer your questions. :)
> But doesn't that imply your having to fork FreeBSD just to use it. If so, doesn't that seem excessive for most organizations?
Well, I wouldn't do it as a fork, because trying to manage it as a fork is exhausting (at least it was for me, when I took over after someone else had setup a fork, trying to move our patches from one releng branch to another was worse than with scripts, and just the pull and push for regular updates was tedious; it probably gets better with practice). At WhatsApp, we had a script that had the release (ex 12.1) at the top, and it would pull the latest from that release branch, apply the handful of patches (/usr/bin/patch < foo.patch || exit), and then run make world/makekernel and then implore the operator to run make install. It wasn't a big script, and we didn't have many patches. You need/want some sort of setup script anyway, so it may as well pull in a couple patches, and make world is a reasonable burn-in test for new servers. You could probably centralize and build binary updates for your fleet too, but we never did. If your organization ends up with zero patches, then it's even easier. I don't think it's unreasonable to expect an organization to do some effort to mange the OS they run on, but honestly, I don't know what the alternative is.
The more important to the business a piece of software, the more likely it is to need a couple patches here and there; for us, all of our servers ran it, so it was kind of important (although, we did end up switching to Linux to harmonize with FB's systems, and that seems to have worked out well enough[1], but then FB had a team to manage the Linux OS install as well). We also had patches for Erlang, and a couple lighttpd patches (nothing exciting), and maybe some for yaws (an Erlang webserver). As a rule, software is broken, but open source lets you fix it :D
> You're not suggesting to use STABLE, correct. You'd still use RELEASE but rarely update it.
Yes, exactly. I don't think I've ever really used STABLE; either CURRENT for bleeding edge testing/development (when needed) or RELEASE for regular production.
[1] there are things that broke, but were fixed (or worked around) easily, and things I liked better on FreeBSD, but mostly I avoided the Linux systems until we ran out of FreeBSD systems, then I quit. :) A lot of the things I disliked were related to how Facebook runs their systems, and I doubt that running on FreeBSD instead would have changed those things; it just would have meant that we would have to port things to FreeBSD that we (or at least I) didn't like anyway. :)
A few questions:
> You'll need/want to develop a workflow where you fetch the upstream source for a release, apply your patches, and build world, release validation involves checking if your patches are still needed and updating them to still apply if needed.
But doesn't that imply your having to fork FreeBSD just to use it. If so, doesn't that seem excessive for most organizations?
> The other way is to use FreeBSD as a stable base
You're not suggesting to use STABLE, correct. You'd still use RELEASE but rarely update it.