[CentOS-devel] moving the CR repo into mainstream release

Tue Nov 22 19:24:44 UTC 2011
Kevin Stange <kevin at steadfast.net>

On 11/22/2011 08:04 AM, Les Mikesell wrote:
> On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes <johnny at centos.org> wrote:
>>> The question is whether this person would be better off getting
>>> security updates that were built post-minor-rev-update or not in a
>>> default 'yum update'.   It's a yes or no question, where recommending
>>> doing one thing and making the default something else doesn't make a
>>> lot of sense.   With/without the CR approach, the non-security related
>>> updates are going to come along for the ride, and you will probably
>>> want them anyway.
>> BUT ... I think that giving the user the choice is certainly preferable.
> You have always had the choice of running 'yum update' or not.  Or
> running it for specific packages.  Or looking at the list it offers
> and making the choice then.  That's for people who are paying
> attention.   The question is what should happen if you don't pay
> attention and just expect 'yum update' to always install all available
> security updates for the life of the major rev like it always had
> before, dragging along some other bugfixes at minor releases.

I've always thought if you are aware enough that you are selective about
updates and concerned about breakage of your dependencies (be they ABI,
API, or otherwise), you'd review the release notes of every package
before updating anything and stage updates into a testing environment
before moving them to production, regardless of whether the updates come
via CR.

In that case, if the CR is rolled into a mainline continuous
distribution by default, you'd still be selectively choosing your
updates based on what they do, rather than blindly installing them and
assuming they won't break everything.

If the user is too novice to care or know better, he is going to blindly
do this either before or after the full QA process.  In my experience so
far with the CR, there have been no significant QA problems with
packages.  Changes upstream that break compatibility will arrive either
way for most people and not rolling them continuously just delays
security fixes and the compatibility breakage until an arbitrary future
time, which really doesn't save anyone any headaches.

Not only that, but even within a release of EL5, there have been updates
which had serious operational consequences, such as the openssl
renegotiation patch, which changed application behavior in occasionally
incompatible ways.

All other things equal, I'd always rather err on the side of a system
service going offline due to a dependency break than exploited due to an
unpatched security vulnerability.

Kevin Stange
Chief Technology Officer
Steadfast Networks
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20111122/1eca75f7/attachment-0005.sig>