> On May 15, 2019, at 12:12 PM, Will Andrews <will at firepipe.net>
wrote:
>
> On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey <jhs at
berklix.com> wrote:
>
>> Batching also means some of these vulnerabilities could have been
>> fixed earlier & less of a surge of demand on recipient admins time.
>>
>> 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.
>>
>> 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.
>>
>
> What admins prefer 8 downtime events instead of 1?
>
> ?Will.
Exactly. If batching 8 (or more) individual bugs/issues together into one
release is really causing admin/manpower overload and angst, then maybe it?s
time in your situation to use the binary updates (which would only be a single
`freebsd-update` and reboot, so there would be no ?sudden unplanned outages?)
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?t
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?d seriously want to run reboots across a server fleet every other day for
two weeks if there were 8 separate patches staggered out? That?s insanity, and
is way more of a PR problem from a ?should we just dump it? perspective. You
mention ?announces an outage schedule for planned upgrade?, but that?s really
its own form of internal batching ? it shouldn?t make any difference if you?re
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?re handling the upgrade process(es), not whether the
fixes are batched or not. Whatever other negative things you can say about them,
I don?t 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.
?\_(?)_/?
Thanks,
?
Matt Garber