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

Hi.

I agree. I think there is no added value to this seperate repo. Besides it
is stalling new releases coming out sooner. +1

Regards,
Marko

I would welcome this very much, it makes my mirroring setup much easier
in that I don't have to update it every time a 6.x release comes out
(since I'm only interested in mirroring the latest release ofcourse)

It is actually going to add a lot of complexity to the mirroring setup.
There will no longer be consistent point release tree's, and the /6/
target will keep changing, all the time. So you will need to carry on
mirroring the entire centos/6/ tree anyway

the exact mechanics of how we implement this would still need to be
worked out.

- KB

ok thanks.

(my mirror is just a rsync with a local ISP's mirror)

In which case you should be ok to retain the existing targets etc, you
will just need a bit more space to mirror into, quite a bit more space.

- KB

Personally, I'd prefer to keep CR separate and have the main releases as
they've been.

The idea behind CentOS is that it is super stable and matches upstream.
I worry that merging CR will hurt the stability. I've enabled CR on some
test nodes and started seeing issues, minor though they may be.

So +1 to keeping the status quo. :)

with the point release going into /6.x/ you will have the option to keep
things as they are as well. Would that cover your use case ? it would
allow you to do the point release switch manually, whenever you chose to
do so.
I hope you are opening bug reports for these issues!

- KB

So long as I can do a 'yum update' and not get the next y-stream
packages until the actual y-stream is released proper, I am happy. In
other words, so long as the stability of my nodes is not effected in any
way, and compatibility with upstream also remains, I am happy. :)
I'm ashamed to say that I neglected to do so. I saw kernel oopses while
working on other things and didn't get back to them... I'll be sure to
file a bug next I see it.

But you also don't get potentially critical security updates until the
full release. That is, yum update won't give you anything.
What stability problems would you expect from updates beyond a point
release? The whole point of an 'enterprise' distribution is the
effort they make to not break api's across a whole major-rev's life.
Would an upstream system break if you selectively update packages
beyond a point release without doing a full update?
That's ummm, strange. Wouldn't you be running that kernel even if the
whole release had been completed?

Having critical updates available in CR gives me the opportunity to,
when I deem it sufficiently critical, to manually pull the package (and
it's dependencies) down *or* enabling the CR repo entirely.
As I mentioned earlier, after enabling CR I started seeing kernel
oopses. I will need to be more diligent when I see the error next time
and submit a bug report.
I really can't say, as I said, I wasn't sufficiently diligent at the
time as I was fighting another fire. I do believe the kernel was
upgraded when I went to the CR repo though. I'll build up another pair
of machines and see if I can reproduce the issue tomorrow.

If the absolute ABI didn't occasionally break from upstream, Scientific Linux would likely not do point releases the way that they do them.

What do you mean? They do point releases so you have the option to
install something that is not horribly out of date. I thought they
rolled out updates into the new point release as they built them, not
waiting for a complete set and install media - and that they had
always done it that way so there was no expectation of getting updates
otherwise. That is, they set up the mechanism before anyone could
know whether point releases would break working 3rd party binaries or
not. But not having such breakage is the main reason to be running
RHEL or a clone. If rebuilding from the stock source produces an
incompatible binary, that is something else.

Upstream backports big chunks of kernel code into point releases,
changing the kernel api/abi. You'll notice this if you have special
HPC hardware which need updated kernel modules. You'll also notice
this if you really care about performance. We carefully test
point-release kernels and only do casual testing of intermediate
kernels, because the intermediate kernels are the only ones with small
changes. (Ditto for HPC hardware vendors...)

Upstream sometimes does big updates of a few user-space rpms in point
releases, because it has become too hard to backport security fixes.
Firefix is a common example, and there are others. These sorts of
changes usually don't happen in an intermediate update.

Upstream has never tested the combination of packages available in CR.
It's easily possible that package A depends on package B being updated
to avoid an obscure bug, but the CR only has A's update. Gentoo users
are quite familiar with this issue.

It is likely that many CentOS users think they aren't bothered by
these issues, but CentOS is used in a lot of production environments,
and I bet there will be some surprises.

-- greg

p.s. Thanks for producing such a good distro!

if you look at the rhn experience for most people - its actually quite
in line with the CR/ process - as if it were just one release moving
along with point-in-time install media being made available. Otoh, its
been a long time since i did anything with rhn, have things changed ?
if CR/ was composed of every and all updates, would that issue be
reduced to some extent ? completely removed ?

Also, keep in mind that people can opt out of the process and lock their
machines into a point release ( eg. lock into 6.1, and only move to 6.2
when they want to ). So it would still be possible for people to control
at that level. Its just that rather than this being the default, it
becomes the opt-in process.
Thats the thing we want to reduce.

- KB

Well, my experience (and I think this is fairly typical) is that I
install all the updates soon after they arrive. So there's no way I
could end up with a 6.0+6.0updates with a single 6.1 package, which is
what CR is intended to do.

During the 5.X series, there was one time that I downgraded a package,
expat, due to a bug that took Upstream a long time to fix. One.
Yes, of course, that's what I plan on doing.

Les Mikesell brings up the reasonable question of whether version
dependencies might save the day. They probably will in most cases, but
with both Gentoo and Debian, I have discovered enough errors in those
dependencies that I don't expect Upstream to get this right,
especially when almost all of their users aren't going to try to
install a single 6.1 package on 6.0. I doubt I'll convice Les with
this argument, but there you have it. As an Enterprise user, I'm not
interested in experimenting with having most CentOS users do something
that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)

-- greg

Not sure where you got that. CR is intended to add many packages and
distribute them more evenly throughout the point release creation
process in a stage way.

Where the media set is not yet done for the future point release, but
all the RPMs are in CR.

It allows us to prioritize building (get enough "dependencies" done and
get the security updates out in the first batch and release them to CR
... then build all the other RPMs in the point release.

We can also build the updates for the next point release (some of the
zero day ... also many Firefox, etc. come out) while we are still
putting together the final point release media set.

It seems to me that you are arguing for a process that puts out staged
sets of updates and then saying CR is bad (which is how we can do staged
updates).
Again ... not sure what you think CR is.

CR is basically dumping all updates as we get them built and working
into a repo that people can install in real time, instead of waiting a
month (oe more) for every single update to complete before we release
anything (our current practice). I am really failing to see how that is
what you are talking about at all ... maybe I am lost.

That's exactly what I'm talking about. Sorry that I wasn't clear. Let
me try again with an example:

Let's say that "foo" is one of the many packages updated in 6.1.

With CR, let's say that "foo" happens to be the first 6.1 package
added to 6.0-CR.

When I install "foo" from 6.0-CR, I am now running a combination of
6.0 + a single 6.1 rpm. This combination has probably never been
tested by upstream; almost all of the upstream people installed almost
all of the new 6.1 rpms together.

I'm here posting about this issue because I'm responding to this
question:
The fact that upstream hasn't tested these rpm combinations means that
there's risk involved.

-- greg

Updates can't be tested against your local applications either - which
is what you'd care most about. But the risk of breakage is small
because upstream doesn't make changes that break API's as a matter of
policy across major revisions - which is the whole point of
'enterprise' versions. If you don't change an API, you don't need to
re-test against everything that uses it.

Well, if you recall what I wrote previously in the thread, I said that
I tested my local applications carefully against point releases, and
not that much against intermediate updates, which tend to be much
smaller and less risky than the changes in the point releases.

With CR, I'd have to do a lot more testing.
You saw my previous comments about how upstream _does_ change APIs,
but seemingly only in point releases? For example, the InfiniBand
stuff changed dramatically through the 5.X releases. Each time they'd
backport a bunch of stuff into the kernel, and release matching
userspace rpms.

Sorry to be repeating myself so much, but I think the point about when
upstream makes bigger changes (point releases) is important for
everyone to understand.

-- greg

But, any combination of the released package set should work together
(within the requires in the RPMs of course).

People update only a subset of packages all the time, mostly because of
custom software that they have done themselves.

But I think I actually agree with one point you are making. I truly
believe the CR should be exactly as it is now ... optional. If you want
to use it, you can easily issue the command:

yum install centos-release-cr

And if you want to do it only as a released version (no CR), then that
is OK too and it should be (IMHO) the default.
You are correct that some ABIs do change ... BUT ... in that case they
will include that in the RPM by something like "xulrunner > X.Y.Z", then
you can only install FOO if you meet the requirements. You absolutely
should be able to install any installable combination that is not hard
coded with a version in the requirements. If you can't then the RPM
requirements are not properly programmed and it is a bug.

FSVO risk, sure. Except that upstream recommends this all the time
when troubleshooting customer systesms.

We have several systems deployed at customer sites that are RHEL
5.3... with the 5.6 glibc. And this was recommended by 3rd level
support, not some 1st level person following a script.

Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on
an isolated network scattered all over the globe physically, so doing
that isn't very easy. And upstream understands this, as well as the
desire from some customers to not change from a particular sub-version
without cause. They may not have explicitly tested various package
combinations, but the commitment to a stable API/ABI means that mixing
packages from within the same major version number is safe with a
small number of exceptions (which are in the tech notes).

IOW, the risk is exceptionally small.

Tom Sorensen

With a nice support contract and an army of willing RH engineers on the
other end of a phone, yes, the risk is small.

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

Johnny,
CR repo is fine, glad we have it. I'd like it to stay optional. We are
using it on boxes not managed by Spacewalk. Boxes managed by Spacewalk
are not using CR:
- no erratas (we are using errata binding)
- packages from CR are going to be moved into Base/Updates repos, but
Spacewalk server keeps all the downloaded packages

So, CR is good trade-off, full release would be better.
Thanks,
DH

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 think the risk factor goes the other way, at least for any machine
that needs updates at all. We just haven't had a well-known exploit
to show it yet.
Maybe it would have been from the beginning, but at this point I'd bet
that there are a lot of CentOS installations that haven't updated and
don't know that they have to do something new and different to get
security updates.
How long do you think it is reasonable to go without updates? I'd
call it mostly a matter of luck if you keep running after any
combination of a remote exploit plus a local privilege escalation are
known by anyone - and that has always been just a matter of time.
If updating is too much of a risk, don't update at all. He's going to
get the one he suggested as a problem as soon as you do a real release
anyway. I don't think he really identified a problem related to having
the minor rev updates come before a new anaconda/iso is available.

It still does, when we get the release done. We are not going to leave
the stuff in CR forever. When the release happens, those people get the
same pacakges as the last version of CR. So they will get the updates too.
I don't know what to tell you ... it all comes down to choices. If you
can't wait to get updates, Buy RHEL. If you don't want RHEL, you decide
what YOU think is the riskiest situation. if you do nothing, centos
works exactly like it does now.

Also, don't forget that we have made MAJOR changes to our build system
and we are building things much more efficiently now than before.

We have also found and fixed several issues like these:

https://bugzilla.redhat.com/show_bug.cgi?idd1739

https://bugzilla.redhat.com/show_bug.cgi?idt3229

Which caused us many bad packages.
You have the option to get it if you want it or you can wait. If an
update breaks your system because of a QA issue and causes you downtime,
that is also a risk. The issue is, you (the user) get to decide .. not
Johnny or Les, but the user.
They do not HAVE to do anything new. CR is an option thing that has a
limited time scope. They will still get updates when we release the
point release.

And judge us by the 6.2 release. It should happen soon and we now have
finalized all our scripting for the new build system for 6.x. Of
course, new issues will mean we need new scripts, but I think we have it
working well now.

We are also expecting several very large build machines from 2 vary
large sponsors .. I can't name them, but everyone knows them.
You are in complete control of this ... we get done when we get done.
If that is not fast enough for you, you must use something else. RHEL
is available.
Not necessarily. We have FIXED many issues from CR .. also even if they
are not fixed, they are called out in bugs.centos.org ... like this one:

http://bugs.centos.org/view.php?idR54

Easy enough to fix if you are expecting it ... someone in CR found it
(also upstream).

The point is ... use CR or don't ... choice is yours. Use CentOS or
RHEL ... that choice is also yours. If you want SLA level update times,
you need an SLA level Enterprise Linux.

On 11/22/2011 08:29 AM, Johnny Hughes wrote:

....

Oh, and another thing. We are automating many processes in the QA
system too...

https://gitorious.org/+centos-testing

Everyone can see tests and people who request to can create tests to
help us check for things that we find are problems.

This process is getting better for 6.x

In case you have not noticed, all the updates for c5.x and c4.x have
been happening within 24 hours (the within a point release updates).

Things are getting better, not worse.

Noted and appreciated. Thank you, Johnny, and the CentOS team, for
working hard on this, in spite of upstream making it more
difficult to do these quickly!

*******************************************************************************
Gilbert Sebenste ********
(My opinions only!) ******
Staff Meteorologist, Northern Illinois University ****
E-mail: sebenste at weather.admin.niu.edu ***
web: http://weather.admin.niu.edu **
Twitter: http://www.twitter.com/NIU_Weather **
Facebook: http://www.facebook.com/niu.weather *
*******************************************************************************

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.

Well my 5c...nothing beeing wrong with CR repo but does it not upstream
provider(RH) deploys updates as they come? so if you put them as you
compile them in the main Repo it would be the same? :) (maybe just chech
the order...)


Regards,
Marko
On Tue, 22 Nov 2011,
Les Mikesell wrote:

2c -> 5c Inflation already? ;-)

You probably haven't read the whole thread. They are discussing possible
changes in ABI, API... that upstream performs at point releases 5.6,
5.7, ... compared to Continuous Repo without expected breakage at
point-release release time.

You better pedal back 35+ messages and track down particular point of
discussion before you respond, if you do not understand what I wrote
just now.

Sorry...must have missed all that mails :D Well as said before it is
always your choice to run yum update - and that way we can preserve
original procedure of RH distro ;)

Regards,
Marko

No. I don't know where people got this idea that RH delivers that way.

When 6.2 comes out (any day now) all of the rpms will be made
available at that time. None of the rpms are pushed into the channel
prior to that.

And unless you do some special foo in RHN your systems will pull down
all of those updates next time you do a "yum update" on them. Or you
can push them to the system from RHN. That makes it no different from
what happens when CentOS makes a point release.

The CR repo is quite different from how RH does it. As I stated
earlier I don't think that there's any significant danger
(particularly compared to having no security updates for months, as is
the current situation with 6) from trickling in RPMs, but it *is*
different from upstream.

Tom Sorensen

Yes,
but after upstream 6.2 has been released you could also run an update
command that is not a fully update, but something like

yum update foo_package

And this command will pull in what is required by rpm configuration in
spec file for foo package + its sub-dependencies.
So, also with upstream, you could be at a certain time, in a mixed 6.1
+ 6.2 level, no guarantee
And for sure upstream can't test every combination of foo update that
doesn't imply the whole 6.2 tree changes applied to your system...

This to say that if CentOS provides an updated package in CR with all
its dependencies we will get the same effect as we would get in
upstream.
If CentOS makes a package foo publicly available but forgets one of
its dependencies (from an rpm chain point of view) you will get an
error when you run the yum command.
(a part from yum/rpm bugs themselves)

Said that, I vote (if I can) for having CR optional and enabled
manually by the user as it is now.

Thanks
Gianluca

- your scenario would end up in a 6.2 system.

- the description "mixed" misdescribes the actual process

- not all rpms will be updated in a point release.

- a virgin 6.2 installation will install (for sure) a rpm that
also exists in a virgin 6.1 installation.


the point is - that this "mixed" combination is a valid one (validated by upstream).


if the are any dependencies - the "requires/provides" internals of the package system
will push the necessary packages.

by the way - CentOS is explicitly taking care of this linking libs and symbols and etceteras




me too


__
LF

Hi Leon,
actually I have not understood if you agreed with me or not (a part
the vote... ;-)
This is what I mean with "mixed environment" and what I tested
(considered 5.6 --> 5.7 instead of 6.1 --> 6.2)

- install base system from rh 5.6 x86_64 dvd iso
[root at rh56 ~]# uname -r
2.6.18-238.el5

[root at rh56 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.6 (Tikanga)

- register the server with rhn

- update some packages
[root at rh56 ~]# yum update yum
...
Updated:
yum.noarch 0:3.2.22-37.el5

Complete!

[root at rh56 ~]# yum update glibc
...
Updated:
glibc.i686 0:2.5-65 glibc.x86_64
0:2.5-65

Dependency Updated:
glibc-common.x86_64 0:2.5-65 glibc-devel.i386 0:2.5-65
glibc-devel.x86_64 0:2.5-65 glibc-headers.x86_64 0:2.5-65
nscd.x86_64 0:2.5-65

Complete!

[root at rh56 ~]# yum update kernel
...
Installed:
kernel.x86_64 0:2.6.18-274.7.1.el5

Complete!

[root at rh56 ~]# yum update redhat-release
...
Updated:
redhat-release.x86_64 0:5Server-5.7.0.3

[root at rh56 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.7 (Tikanga)

- reboot
[root at rh56 ~]# uname -r
2.6.18-274.7.1.el5

[root at rh56 ~]# rpm -qa|wc -l
442

So, after a pure rh e 5.6 install l I then directly updated 10
packages from rh el 5.7+updates bandwagon...
While the other 432 packages remained as stock rh el 5.6 original dvd

This is what I call a mixed environment....
Note that if I run
[root at rh56 ~]# yum update
I'm proposed this:
...
Transaction Summary
=======================
Install 1 Package(s)
Upgrade 140 Package(s)

Total download size: 116 M
Is this ok [y/N]: Exiting on user Command
Complete!

Is this supported by upstream? I think so.
And the same process would be with CentOS supposing they provided in
CR repo the 10 packages above (actually 9, considering redhat-release
that doesn't carry on any dependencies btw....)

Hope that this explains better my point about mixed-environment, and
the final system not being a 5.7 installation...

Gianluca

Hi Gianluca,

Am 23.11.2011 um 16:39 schrieb Gianluca Cecchi:

i agree with you :-)

To evaluate the implications of the CR repo - like it is or as a
default repo - i suggest to define some major scenarios. The way
people use yum update-commands explicitly/manually will be always
a continuous spectrum (also included: across more then one
releases e.g. "5.3... with the 5.6 glibc").

One scenario would be - a system that has CR enabled and therefore
is in a state that i call e.g "6.(coming release)" minus packages
that are not already build.

One such state was mentioned in this thread. A full updated system
with one (expat) package downgraded. This example had an issue but
not as result of a continuous update.

If there are any real issues - i would like to compile them.
Even the mentioned kernel oops could have there cause elsewhere.

One good thing to keep in mind - the CR rpms passes through a
"stable and completely QA'ed process".



I would say by design. If a point releases is out (upstream) - the
CR repo is able to provide a package with ALL necessary rpms that
resolves the corresponding dependencies.

Even if kernel-updates of point releases change api's, the dependencies
of userspace (kernel) packages should reflect necessary requirements.

thats it.

I understand the mentioned stability hints of some people. I just
want to show up that a reasonable assessment must include the context.
We are not speaking about fedora or other quite interesting distros (as
already mentioned) but about an enterprise distro. This means, it is
fairly stable over the whole lifecycle (centos way to build the distro included).

(Example: Even if a major update is done (php 5.1 -> 5.3) the
"enterprise focus" forces upstream to provide this update as option.

Sure - and i didn't explain my point of view correctly.


The above is more technicaly. The essential question can not be answered here.
Anyone have to consider there own underlying conditions. Centos can only offer
the options as needed (e.g. CR as option).


That's my EUR 0.01

Version dependencies are supposed to be noted in the rpms and this
isn't gentoo - the apis aren't generally supposed to be changing at
all or you couldn't expect your own and 3rd party applications to
continue to run.
I've fairly routinely updated individual packages only across minor
rev changes or held some back without problems. Your argument would
be more convincing if you had several examples of update combinations
not prevented by package dependencies that will break something.

Hello

I agree. The CR-Repo is very much appreciated and - imho - should have a place in the mainline repo.
This might also take some load off of the mirrors during point release time (as most packages from /os
are already updated via /cr - for those who use it. Did I get that one right?)
Changing my mirrorlayout should be no problem.

+1

all the best
Christoph

On 11/01/2011 02:49 PM, christoph wrote
that does imply that we get hardlinking right, and people are running
rsync with -H

- KB

It looks like there is need in little clarification / saying it more clear

Vreme: 11/01/2011 03:15 PM, Karanbir Singh pi?e:
Does this means CR packages would go into updates repo? I use ISO = os
repo, + updates repo, for mirroring.

/>>/ This might also take some load off of the mirrors during point release time (as most packages from /os
/>>/ are already updated via /cr - for those who use it. Did I get that one right?)
/>>/ Changing my mirrorlayout should be no problem.
/>
-H is used, thanks to http://wiki.centos.org/HowTos/CreateLocalMirror
I assume, /cr will be emptied resp. moved to /updates once the point release is done?

cheers
Christoph

Can you please properly reply to posts? I receive them as separate
threads and it is hard to follow.

Thanks

Just so I have it straight:

- OS won't change from the way it is handled today
- Updated packages between point releases still go to Updates
- Packages that are part of the next point release (that are going
into CR now) will instead go into Updates under the new plan
- When a point release comes out, OS changes to the new point release
and Updates gets a cleanup to remove CR and Updates that are part of
the new point release
- Cycle repeats

It seems to me that as long as you are doing any network installs just
from the OS tree, it shouldn't change from the way it is today. Under
the new plan, everyone is basically opting in to receive the CR
updates. I assume the comments about needing more space to mirror is
because the CR tree basically replaces a large portion of the OS tree?

I am absolutely in favor of a "continuous release" CentOS 6 that's
permanent. For a lot of CentOS users, I think there's no real advantage
to holding back between minor versions and this avoids the need for
users to knowingly opt-in to retain access to constant security updates.

We don't really need updated media since our kickstart files always just
pull in the updates repo (and now CR also). Updated media as a slower
process in the background is fine with my company.

As a mirror we certainly have the space to do this. I would hope this
can be done with hard-linking to reduce the space demands on others
where space is more of an issue.