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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
