Il 02/08/20 19:09, Alessandro Baggi ha scritto:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
I press send wrongly.
Sorry, but you are wrong about this.
If I want SLA and QA I will use RHEL.
Now permit me to say one thing: the update on my machines, failed in a so BAD way that my first thought was "WTF? they tested this fix?" and I'm not the only one that who thought about this. I expect that a package is tested to not break a machine/service like for other distro like debian, opensuse, ubuntu and this is DIFFERENT than expect a defined SLA or QA level. How I can expect SLA from CentOS for personal usage and free? But if this happen on CentOS I read "Eh, you want SLA and you should use RHEL", ifthis happen on Ubuntu "Ah, don't use Ubuntu, I abondoned it for this type of problems"... I need only that the update does not destroy the entire installation. Now, if expect that a distro, with a strong reputation like centos, make test on a package that could break the boot process of a system, for a good number of usage case is not requiring SLA or QA, is only expect a good practice like I would expect for other distro.
When I release a patch/fix to a script or an RPM package or php page or python script, before I apply the change I ensure that this change does not break anything. I'm not sure about this? Good I'll wait to push it and test it again ( this not imply that bugs are not present) but this is not a SLA request man because I know that centos can't offer it.
Probably this is a my misconception, but hey I'm really and very surprised that this happend in a bad way (specially on the upstream). As I said, I will use again centos and won't expect any type of SLA, QA, fast release in a different way like for the previous version, I can only send a thank you to the CentOS team.
As Johnny explained this happened and will happen in the future, this problem is not related to CentOS directly and the great job that Johnny done today is amazing.
My 2 cent.