FreeBSD has serious problems with focus, longevity, and lifecycle

[Royce Williams]

John's trying to manage risk.  Switching from RELEASE to CURRENT adds
a lot of risk and churn, when most folks in this class of use case
just need a few very specific drivers and bugfixes (what some OSes
call "hotfixes".)

John sounds willing to trade a little bit of local risk (and testing
time) in exchange for a way to self-serve a hotfix without abandoning
RELEASE.  How can we enable that?

There are simple cases -- the ones that just need a few files and a
kernel module -- that seem within easy reach.  For example, the eRacks
guys generated these handy binaries for mps(4) for 7.4, 8.0, 8.1 and
8.2:

http://blog.eracks.com/2011/08/lsi-logic-6gbps-mps-driver-for-freebsd-8-2-release/

For me, this was perfect: I got to have my cake (tracking 8.1-RELEASE,
and using freebsd-update) and eat it too (support for specific newer
hardware).  If security updates break my mps(4), I'm on my own -- but
it's still a much better balance of risk for me than switching to
CURRENT.

I know that some fixes are harder than just adding a kernel module.  I
know that the standards for releasing errata are high, and they should
be.  But I wish there was a way to optionally lower that threshold and
say: "Yes, I know this might eat my data.  Let me judge and test that
for myself without otherwise abandoning RELEASE."  If there was a way
to mark hotfixes as "worked for me" (to let the better ones bubble up
to the top), we non-coders could even help manage the list.

I can't do it myself, but I would happily help brainstorm, test  --
and commit $100 or more, Kickstarter-style, to fund someone else's
work.

Royce