On Thu, Nov 03, 2016 at 07:42:01PM -0600, Theo de Raadt wrote:
| We need to learn somehow. Sometimes the commit-pullout-recommit-
| pullout-recommit-pullout-recommit-pullout-recommit-pullout-recommit
| process is too costly. Want to help shortcut? Run snapshots?
|
| Afraid of that? Don't worry, it happens randomly, rarely and
| sporatically and you likely won't get hit except 1 round of builds.
| Someone will hit it first, we hope.
|
| Otherwise run releases, and don't participate in the process that
| makes the next release better. We ask for a bit of snapshot use, but
| you get to make your own choices.
My approach the last few years has been to very frequently update
local, less important, machines (my laptop and workstation). Then,
when the snapshot is fine on those machines (which it usually is), I
update my home gateway with some of those snaps (it has a different
workload, so it tends to excercise other codepaths possibly finding
bugs I don't find on my laptop/workstation - and besides, reboots are
slightly more annoying, since I lose connectivity for like three whole
minutes while I wait for the machine to come up again).
When it's also fine on my home gateway, I sometimes roll it out to
other machines that run services on the internet. Here I don't want
to reboot very frequently: that introduces brief downtime. But
keeping track of source-changes@ and ports-changes@, sometimes bugs
are fixed (think Open/LibreSSL or random bugs in ports for some of the
software I run) which make upgrading a bit more pressing.
Anecdotally, snapshots are quite stable. My workstation and laptop
almost never have problems, so I'm happy. And when I do run into
issues, I try to report them to bugs@ so that they're fixed before I
move those more important machines forward. Since they must move
forward at some point... :)
One thing I've not been doing very much lately is testing diffs that
are sent to tech@. Time permitting, I'm hoping to pick that up again
soon, applying diffs to machines that are likely to be affected.
Anyway .. this is a very common and easy way to help OpenBSD
development: give feedback about new code. I guess it's the easiest
approach after donating to the project.
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
