On 06/20/2014 06:56 PM, Stephen John Smoogen wrote:
On 20 June 2014 10:43, Tim Bell <Tim.Bell@cern.ch mailto:Tim.Bell@cern.ch> wrote:
> > So, for all periods outside the active time that a tree is live, the CentOS 6.4 tree > is radically different than the RHEL 6.4 tree. That is the issue I want to address. > CentOS 6.4 does not equal RHEL 6.4 ... and it is especially tree after the 6.5 > release. I think that there is obviously an issue in perception that people think > they can stay on an old tree and get the same thing they would in RHEL,, and > they can't. > They can't on CentOS ... they can't on Scientific Linux, they can't on any of the > rebuilds. > >From my understanding, RHEL by default gives the same (i.e. you follow the tip) unless you turn off yum. It is only if you pay extra for EUS do you get the branch updates. >From what I can see, - There is interest in clearly marking the release with a date to show from which source it is taken when the base code was built. - There is interest in maintaining some correspondence. As you mention, it is currently like that for Scientific Linux CERN and we have not encountered confusion with our community. How about we take the following approach - We define the point release as being the one that Red Hat define as their point release in the code from which the build is derived (i.e. the contents of redhat-release in the git repo). This is the closest indication of the correspondence with RHEL. - We define a date based extension which indicates the date that the build was done. This would produce a version number along the lines of 7.0.1406 which would not be confusing to those who have been using the distros previously and indicate the time based nature of the work.To extend this a bit further I was going to say
7.0.core.201406 # Rather not be Y2100k compliant :) 7.0.storage.201407 7.0.openstack.201408
that way it covers everything:
Upstream release: 7 Upstream starting point branch: 0 Downstream SIG: core, storage, openstack, desktop, etc etc Downstream Release Date: 201406, 201407 etc
The files that need to be parsed by tools by vendor tools (eg Oracle wanting 6.5 and not running on 6.4) can have the two parts that are needed. The parts that community support members need (which SIG was this and which releasedate in case of say openstack doing weekly snapshots.. ) are there.
And no I am not a stickler on 201406 versus 1406 .... just like my ISO8601
-- Stephen J Smoogen.
This could be workable. Ditching minor version would be harmful and would create havoc with newbies. And people doing CentOS support would go out of their minds explaining the difference.
I personally would HATE to promote CentOS by consulting release timetable so I can relate RHEL to CentOS versions. I would most likely just give up giving support and mind my own business. There is a line over which I would not be ready to give back to the community anyway I can. Havoc of "So what version of CentOS is for RHEL 7.3?" is definitely that line.
Johhny, I still do not understand what you are trying to do. And I fall under top 1% of population by Mensa IQ test. Imagine person with IQ 120 with poor English skills. Imagine all those CEO/IT Head's and Managers perception of the Linux world. Imagine what all those others will think/reason it ALL of the highly tech people in dev list are screaming "bloody murder"!?
Huge number of people will still use CentOS 7.x for Desktop/Laptop or standalone Servers. No docker, not even KVM. Just plain bare metal distro. And with CentOS/RHEL visual improvements and reaching technology level good for Desktop/Laptop use (Steam for Linux, Chrome/Chromium, modern kernel) things are actually looking up. Kernel with Real-time Audio support could make CentOS stable media distro, for "install and forget" systems.
And you would kill all that by alienating all those people with worst PR nightmare you could ever create. 90% of Linux users will just say RHEL != CentOS anymore, no matter what you would say. And everything would start loosing traction. On the eve of new era for CentOS.
Lets get back to me not understanding your reasoning.
I and 90% of other admins who install and administer our own systems will install 6.4 and do "yum update" and we will be on 6.5 Right? So for them we should have "please keep this system properly updated with 'yum update' to be safe" warning where ever we can, logins, mail to admin mail account, in logs. Either you keep minor version or have timestamp, they will do what they want.
That leaves those images expert admins are going to work with. So, you create docker image with 6.4. And you want what? To update to correspond to only 6.4 EUS (whatever) updated packages? Why not just create another repo for 6.4 EUS updates so that image uses 6.4 os/base repo + updates-6.4/updates-64 repo? SiG would manage that repo and everyone would be happy.
If you do not want to keep that docker image on 6.5 then "yum update" will bring it to latest, and again everything is solved.
So basically, If I understand you correctly, you want to solve lack of repository for updates against 6.4 version with PR disaster. Right?