Date: Wed, 15 May 2019 12:16:37 -0400 From: Matt Garber <matt.garber@gmail.com> To: Will Andrews <will@firepipe.net>, "Julian H. Stacey" <jhs@berklix.com> Cc: FreeBSD Stable ML <stable@freebsd.org>, "freebsd-hackers@freebsd.org" <hackers@freebsd.org>, FreeBSD Core Team <core@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: Re: FreeBSD flood of 8 breakage announcements in 3 mins. Message-ID: <6CE35CEB-C2AB-47B1-AA86-BC9C91B2B8A6@gmail.com> In-Reply-To: <CADBaqmj5wAP-uG6RmOA_zTgQ1VG%2BT0CyUie3SYks4ooPqPRpOw@mail.gmail.com> References: <CAOtMX2hA2AfVuNrFxDhXLpY74UAcrWXSd0GjZ1uJJq2vZ5T1qw@mail.gmail.com> <201905151544.x4FFiR0G067138@fire.js.berklix.net> <CADBaqmj5wAP-uG6RmOA_zTgQ1VG%2BT0CyUie3SYks4ooPqPRpOw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 15, 2019, at 12:12 PM, Will Andrews <will@firepipe.net> wrote: >=20 > On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey <jhs@berklix.com> = wrote: >=20 >> Batching also means some of these vulnerabilities could have been >> fixed earlier & less of a surge of demand on recipient admins time. >>=20 >> An admin can find time to ameliorate 1 bug, not 8 suddenly together. >> Avoidance is called planning ahead. Giving warning of a workload. >> Like an admin plans ahead & announces an outage schedule for planned >> upgrade. >>=20 >> Suddenly dumping 8 on admins causes overload on admin manpower. >> 8 reason for users to approach admin in parallel & say >> "FreeBSD seems riddled, how long will all the sudden unplanned >> outages take ? Should we just dump it ?" >> Dont want negative PR & lack of management. >>=20 >=20 > What admins prefer 8 downtime events instead of 1? >=20 > =E2=80=94Will. Exactly. If batching 8 (or more) individual bugs/issues together into = one release is really causing admin/manpower overload and angst, then = maybe it=E2=80=99s time in your situation to use the binary updates = (which would only be a single `freebsd-update` and reboot, so there = would be no =E2=80=98sudden unplanned outages=E2=80=99) rather than = tracking src and remediating each individual bug at a time. I understand = that might be mutually exclusive with other reasons why you don=E2=80=99t = already use binary updates or prefer to track src for the base system, = but there are always compromises and trade-offs to everything, and = batching seems preferable to any alternatives. You=E2=80=99d seriously want to run reboots across a server fleet every = other day for two weeks if there were 8 separate patches staggered out? = That=E2=80=99s insanity, and is way more of a PR problem from a = =E2=80=98should we just dump it=E2=80=99 perspective. You mention = =E2=80=98announces an outage schedule for planned upgrade=E2=80=99, but = that=E2=80=99s really its own form of internal batching =E2=80=93 it = shouldn=E2=80=99t make any difference if you=E2=80=99re technically = pushing 1 or 8 bug/security fixes during that pre-identified period of = time: all of your other internal processes like maintaining a test group = for detecting regressions, using boot environments (or other storage = features) to allow for rollbacks, etc. all continue to work as intended. Any potential negative PR within your company/organization seems like it = would be related to how else you=E2=80=99re handling the upgrade = process(es), not whether the fixes are batched or not. Whatever other = negative things you can say about them, I don=E2=80=99t hear enterprise = admins begging that Microsoft/Oracle/whoever would dribble out patches = one at a time each week instead of combining them like they do; it seems = like it works just fine for everyone else. =C2=AF\_(=E3=83=84)_/=C2=AF Thanks, =E2=80=94 Matt Garber
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CE35CEB-C2AB-47B1-AA86-BC9C91B2B8A6>