On 11/21/2011 06:05 PM, Les Mikesell wrote: > On Mon, Nov 21, 2011 at 5:50 PM, Stephen Walsh <steve at nerdvana.org.au> wrote: >> On 11/22/2011 10:43 AM, Tom Sorensen wrote: >>> FSVO risk, sure. Except that upstream recommends this all the time >>> when troubleshooting customer systesms. >> >> >>> IOW, the risk is exceptionally small. >> >> With a nice support contract and an army of willing RH engineers on the >> other end of a phone, yes, the risk is small. > > And you are running the same code... > >> For $Johnny_webhost, who takes his daily income from his business, and >> can't afford the above mentioned support on his rack full of EL boxes >> (which is why he uses centos), he needs to balance the risk of losing >> customers due a security incident vs running a full up to date and >> stable system with a mix of current and upcoming release packages, and >> all with the knowledge in his head and what he can get from the main >> centos list (most of which last time I looked appeared to be a >> conversation about why you should use ubuntu over centos). >> >> The Lowest Common Denominator is the one we need to think about here. >> The end user that wants EL stability and security, but can't afford to >> spend the money on upstream subscriptions. > > 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. We have a process that we use to build and test packages, and when we finish we have what we call a stable and completely QA'ed process. We offer, at some increased risk (due to less QA), a repo staged updates. We made this very easy to get ... just run yum install centos-release-cr if you want it. But we give the customer the option to take the increase risk or not. I think this is the RIGHT way to do this. I know that it means if you do not know how to manage your machine (and issue a very simple command to get CR) then you don't get it ... but I still think that the full repo with full QA should be the default. We can recommend that people go ahead and do CR in the release notes, but I think it is a mistake to turn it on by default. If you would rather add it to the MAIN rpeo file (CentOS-Base.repo) and have it off, then require people to edit that to get it, that is fine by me too ... but I think a simple command (yum install centos-release-cr) is much easier than editing the CentOS-Base.repo file anyway. Then, we make people who want CR happy, they can install it and it works after install ... and we make the people like Greg happy because he does not have to do anything to turn it off if he perceives the risk is too great to have it on. That way, we can recommend (through the release notes) that people use it ... but give them the final option. That's my $0.02 -------------- 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/2db9387d/attachment-0007.sig>