On 06/09/2014 07:41 PM, Ned Slider wrote: > "Finally, a versioning scheme such as this would allow us to version and > track builds that have in the past struggled in the x.y regime (eg. > cloud images, updated at point in time against security vulns or to > incorporate vendor environment changes)." > > Finally I see the first hint of a technical issue that might actually > require a solution, but I still don't see it needing such a perceptually > important change as to altering the release numbering. There are a couple of things here worth bringing up 1) the focus on the distro has always been on the major release ver, we always communicate ( or try to ) that the person is running CentOS-5 or CentOS-6, and not so much 6.4 or 6.5; these are point in time labells. So they should be considered that. 2) A clear example of what the datestamp tries to workaround is yesterdays docker updates ( and the AMI and GCE images etc ) that were done to CVE fix openssl content. These are not marked as a point at all, just a centos-6-x86_64-20140609 ( and in most cases, the link that people hit is for centos-6-x86_64, which points at the latest images ); this is becoming more of an issue as the cloud side of things grows, even within CentOS we've seen a massive increase in uptake on that side and I am sure everyone sees that. 3) the CentOS Linux distro is going to do no more or no less releases than RHEL is. There seems to be a bit of miscommunication here that having a datestamp will allow us to do monthly builds, sure - but we wont. The main distro is going to be an exact 1:1 rebuild of RHEL, as we've done in the past, to be no worse than we were before - hopefully improving as we move forward as a larger group. 4) Communicating a relationship between the point release in 7 at RHEL and CentOS isnt something that goes away either. There have been some great suggestions on this list already as to what we could do to retain that message. eg: Maybe CentOS Linux 7.1406 ( 7.0 ), sort of a scheme, and for those who prefer names, maybe we do the Alpha, bravo, charlie or something like that. In either case, the A, B, C will map exactly to 0, 1, 2 - with no interim release going into the main distro. 4.1) Another interesting idea is to have /etc/redhat-release contain the upstream versions, while /etc/system-release points to /etc/centos-release that can have a centos specific release string ( that itself can still contain upstream references ) 4.2) Anaconda will, ofcourse, still need to retain the same version strings are upstream, otherwise driver disks from third parties are not going to work. 4.3) yum still consumes release data, again - pointing to /ReleaseVer/ only, and that will be un-affected. People tweaking it to local flavour can still do so. 4.4) lsb_release info can still ( and really -must- ) report the upstream versions, so manifests written on CentOS can still work on RHEL and vice versa. 5) SIG's and variants can and will do their own releases, based on their own roadmaps, using CentOS Linux as the baseline platform and they can chose to do as much or as little code share with the platform ( but ideally, there will be some value to it, which is why they are here in the first place ). They can then chose to do releases that branch from CentOS, but they cant call it CentOS Linux. eg. if the storage SIG The problem definition is mostly down to : - finding and focusing on the ReleaseVer rather than the point releases, but still retaining the ability to map the iso builds so external drivers, kickstarts, hardware upgrades etc an be identified and managed in sync with what happens in RHEL. - Making sure that the cloud and instance images have some level of relationship with the mainline distro, this is an increasing issue we need to handle. - Try and provide the SIG's with a way to do something similar, diverge, rename their delivered content ( eg. CentOS Ceph Server ), and yet retain relationship with the mainline distro - RHEL point releases that contain different content are no longer confused for CentOS point releases. A problem recently highlighted with the openssl heartbleed issue where every Scientific Linux 6 install was impacted, whereas only a part of the userbase on CentOS 6 was, and a different set of people on RHEL 6 were. One could argue that everyone who had done updates on CentOS was impacted, and that is true - the situation becomes grey when you consider people who were on point releases and were updating against different release tree in SL, CentOS and RHEL. - This will make it easier for people to maintain site-local content and golden images that they can curate on their own, policy and deliver around it on their own, without needing a new versioning schema. Lots of hosting companies and voip providers do this, and everyone has their own process's and policies, which are always going to exist - but they all also have their own versioning, which always leads to confusion. Interestingly, almost all of them include a datestamp in their golden mark. In summary : there are various things that line up, and there are many potential wins that we can draw from here, without changing the user experience or impacting technical legacy. If we are, then we need to find a way to not, or find a way to work around it. Also, CentOS-7 is going to be coming up soon - we have the buildlogs already going to a list, and now also on http://buildlogs.centos.org/ - not putting rpms there as yet, since we dont want that machine ( and vitelity.net who gracious donated the machine ) to complain. We are going to try and get a few more machines behind it, and the buildsystem output becomes visible right away, in near real time. Highly encourage people to QA / QE in sync with the builds ( bootstrap from the 7rc isos ). Fairly sure we can iron out issues ( and come up with a better naming if it were so ) that still resolves the issues at large, helps us build the centos image, and yet no technical legacy wreackage. lets not forget, we've been ahead of RHEL delviering better value at many places. we had the X.y regime before they did, and i wont be surprised if they struggle to maintain messaging around the relevance of a X.y into the future ( but thats a different problem :D ) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc