On 04/01/2015 10:10 PM, Lamar Owen wrote:
>> Yes, not very wise... Karanbir corrected very quickly the content of
>> the redhat-release file, because it was totally different from 7.0,
>> and broke a lot of scripts and applications.
> The issue of the content of redhat-release was a serious and valid one
> that actually broke stuff; the ISO name being different from expected
> doesn't break stuff. If the ISO name broke stuff, then that would be
> different, and it would have already been fixed.
This is the key bit here - were not trying to break anything - we are
trying to keep things sane for folks who are already invested in the
platform while also allowing other people to do interesting things.
You brought up the rolling builds, and yes - we've been doing it. Its
been immense value ( over 100K downloads for the 2015 Feb builds as a
point of reference ). for other process's like the Atomic builds,
needing the nightly, weekly builds has been key to their ability to get
the technology moving. There are a lot of such examples around, but I
will admit many of them are silo'd away slightly from this list - eg.
the docker traction we have does not typically feedback here to this
list and perhaps not into this audience. But should you want to move
into container space, CentOS today represents one of the best all around
experiences either on host or instance side.
The story is similar on the Cloud side of things, we have a ver large
cloud instance base - if i were to fancy a guess, I'd say 20% of the
centos install base is today in cloud ( and this is largely only
offprem, including onprem the numbers might go higher, but there is no
way to tell since they could just be real machine instances ).
Putting all that aside, the baseline assumption that we should all be
mindful of is that in real terms there is no CentOS point release : any
centos install, regardless of where it originated from, yum updated to
the same point in time will have the same package manifest, and should
deliver the same feature set ( with some exceptions, like environ
specific workloads might have local flavour - you wouldnt expect cups on
an GCE instance for example ).
So what the changesets have done ( and lets be fair, these changes like
the iso name changing to line up a date stream rather an an arbitary
point in time isnt a huge deal, you can just rename the file locally if
you so wish ), effectively line up and help deliver on that.
Let me highlight this with two examples:
- the Amazon instances we provide have been updated out of band, to
cover for the security issues that have wider impact, heartbleed and
poodle and all that stuff : labelling those as 7.0 makes no sense since
it does not deliver on a 7.0 feature set, it delivers a CentOS-7/Dec
2014 update set.
- Second example is that when you look at a machine and it says 5.5 its
hard to explain to the user that his machine might be 5 years out of
date, there is a baseline cultural expectation that a release is either
maintained or not - and having the conversations around CentOS-5 being
maintained but not 5.5 isnt easy. Remember that this list represents the
folks who really know, and know well, both the ecosystem and platform as
well as their workloads and userbase - there are a lot ( a majority ? )
of CentOS user who dont get this. For them to line up with a
CentOS-7/2014-06 and CentOS-7/2015-03 immediately makes sense. it makes
it easier for us to communicate the delta in security and bugfix that
they dont have on there.
And I think the overall solution we have in place right now, really does
this well in that we clearly communicate the upstream relationship,
while still being able to deliver the common message on and around the
centos-release spec. If there are tangiable situations where this change
causes harm, then I am very willing to reach out and help find a
solution : dont want to break existing installs nor reduce the info
available.
The other thing here in this conversation is also that there is a large
emotional resistance to change. Folks expect the numbers to line up in a
specific manner, and they dont - the contents of the images however
still give you the metadata you need ( both ways, they should give you
point in time, and release from rhel that we derived/built from ).
Happy to pickup and work through individual concerns people might have
around this. But in real terms, please note that there is no change in
the content being delivered. We are only opening up options to line up
various media and point-in-time images.
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
