On 7/9/21 11:44 PM, Patrick Riehecky wrote: > On Fri, 2021-07-09 at 23:14 +0300, Manuel Wolfshant wrote: >> On 7/9/21 7:32 PM, Patrick Riehecky wrote: >>> I'm really torn on these ideas. >>> >>> I guess I'm trying to sort out who we'd be helping most and who >>> we'd be >>> harming least with each of these ideas. >>> >>> Is there a CentOS user community of folks who apply nightly updates >>> but >>> don't respond to errors during that process? >> yes, there is. I know of installations ( not mine :) ) which have a >> "yum -y update " run from cron.daily > I guess it is a workflow issue, Yes, it is. > but most of my hosts apply updates nightly and when they fail to apply I (or another team member) look into why. Because you are part of an organization with proper infrastructure, procedures and qualified people. Now think about a small shop with 1-2-3 systems, no IT budget and no qualified personnel (*). They got help initially and installed/configured the machines. Knowing that they have no admin or external contractor, the person that did the installation tried to help and left the machines in a state which more or less keeps them updated automatically ( it's good to stay updated, right ? ). Maybe the failures are even mailed to someone.. but that someone does not read the mails because a) (s)he has actual but completely different work to do as $DAYTASKS, b) there were never important automatic mails so reading those is a pure loss of time c) does not even understand what (s)he reads in those mails. Not to mention the more interesting aspects generated by botched updates ( see RHSA-2020:3216 ) which might lead to d) the systems hung so no way to read the mails anyway. > > To my mind this is compounded by AppStream/Modularity where some of > your streams may make some of your updates fail in new/interesting > ways. > > I guess I'm wondering how far off the Best Practices we want to support > in Jan 2022... _THAT_ is a very good question. I will not hold my breath waiting for a convenient answer. > > "Set it and forget it" nodes that aren't "managed" by anyone are always > a problem. Yes, they are. You are 1000 % right here. But yet they exist and leaving them behind because "we do not care" is neither polite nor indicated ( from my point of view ). > But are those folks likely to blame us for issues Again, yes, they are. " RH did it again, it worked yesterday but last night it suddenly stopped working. And when I looked, guess what ? It was not the OS I installed !!!!!11111" > vs folks with managed systems who are "reading" the error reports from dnf- > automatic (etc) and aren't aware of Stream8? The Universe is large and it has many aspects :) > I guess I'm not sure upgrading folks to Stream8 is in the 'predictable' end of life workflow. > from my point of view , it is not. I cannot speak for CS8 but in C6 and C7 I had ( rare ) issues when proprietary apps stopped working after upgrading a lib or another. Or the kernel ( see Cisco's vpnclient whose kernel module could no longer be compiled after a certain update of the kernel ). I live in the world of EDA tools for VLSI development and support for said tools is already problematic when running on more "classic" OSes . A moving target like CS8 is not even envisioned. I asked a developer from Synopsys a few years ago "Why do you always support your application only on OSes which are at least 2 minor releases behind the current one ?". His answer ? "We wait 6 months for the release to stabilize and we need another 6 months for internal testing" (*) I know, they should use an embedded router and externalize all IT, maybe host everything in cloud. Reread the "no IT budget" part. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210710/eeb1bbf1/attachment-0005.html>