[prev in list] [next in list] [prev in thread] [next in thread] 

List:       centos
Subject:    Re: [CentOS] Boot failed on latest CentOS 7 update
From:       Alessandro Baggi <alessandro.baggi () gmail ! com>
Date:       2020-08-02 17:34:35
Message-ID: 3343dab5-f725-1153-9923-206812f9e86d () gmail ! com
[Download RAW message or body]


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?=A0 But if this happen on CentOS I read "Eh, you want SLA =

and you should use RHEL", ifthis=A0 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,=A0 make test on a package =

that could break the boot process of a system,=A0 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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[prev in list] [next in list] [prev in thread] [next in thread]