On 06/07/2014 12:00 AM, Kay Williams wrote:

...

On Friday, June 06, 2014 5:44 PM, Karanbir Singh wrote:

hi,

Taking on board the community and environment expansion that is taking place around the CentOS project, the CentOS Board has been considering how best to accomodate these efforts.

I'm attaching here a plan put forward by the board towards that aim.

Thoughts ? Comments ?

I am still new to the community and so wish to be careful expressing opinions. Certainly, my thoughts will not take fully into account the thoughtful work that has been underway in the community in advance of CentOS 7.

Most people are new on here. This list was very low traffic before the concept of SIG/variants. Don't hold back simply because you feel 'new'.

Similarly, the folks who speak up are the community voices we hear. We (the board) can end up with tunnel vision or a skewed perception of how things are being used if we don't get feedback. We may not agree. We may do something you don't like, but your opinion WILL be fully heard.

TL;DR-> Please feel free to speak your mind on the list. Backing up your points with facts/technical details makes it stronger, no matter how new you are.

That said, I hope you will permit a few observations.

The first is that it is very powerful for CentOS to maintain the simple message that it has had from the start - 100% compatibility with Red Hat Enterprise Linux. This is what allows people to use and trust it for running their organizations. The more CentOS feels exactly like "RHEL - but without support", the more people understand it and take stock. On the other hand, the more it feels different, the more people feel/fear that they should consider alternatives - maybe Scientific Linux, maybe non-RHEL distributions. They don't want to do this, but stability and dependability are key. Their businesses, and their reputations, are at stake. These are the exact concerns I heard expressed, unsolicited, from other attendees after the CentOS presentation at the Red Hat Summit in May. In particular, there was a great deal of confusion about SIGs/variants, what they were, how they would be implemented, and whether the introduction of variants would mean that CentOS would no longer be compatible with RHEL. Clearly, the goal is to maintain compatibility. But even small things that introduce differences create FUD (fear, uncertainty, and doubt).

The second is that, at an industry level, even minor inconsistencies, like versioning schemes, do more than just raise concerns, they introduce real impediments. OEMs test and certify their hardware for specific versions of RHEL. ISVs likewise test and certify their applications. Previously they could say "this hardware/software has been tested against RHEL 6.3". And everyone knew this meant that CentOS 6.3 would work against it as well. But with a new versioning scheme, things are less clear. Now, OEMs/ISVs need to say "compatible with RHEL 7.2/CentOS 1506". Or maybe they just say RHEL 7.2 and users are left to translate this to CentOS versioning. But whether it is something OEMS/ISVs, or users do, why force there to be a translation at all?

Seems better to work around issues with the RHEL versioning scheme than to let something that is already potentially confusing (variants) create tangible issues for existing users, and for the broader industry.

Agree, however appending to the 'RHEL' release schedule (7.1.xx) could be misconstrued as RHEL's z-stream support offering. We were trying to avoid confusion in that way.

On 06/07/2014 05:56 AM, Tim Bell wrote:

A few quick thoughts....

1. Does the SIG need a naming convention also, e.g.

CentOS-7.1407-Cloud-140805

i.e. the cloud SIG based build done on 5th August 2014 based off the

CentOS 7 tree in July 2014.

That is what we are looking for, a 3rd component for the SIGs, so that they can (if they need to), delineate something that is different on the end. It allows for mix and match as the SIGs see fit.

2. The minor release number is not in the naming convention. Is this a question of length ?

CentOS-7.0-1407

I am thinking as we get to beta releases of 7.1, having a mechanism to

name the beta releases independently of the production ones would be useful.

The issue with 7.0, 7.1 or 7.2 versus 7.YYMM is this (I'll use 6.4 and 6.5 and real dates/times in my example):

CentOS has never supported older versions than the current release. Red Hat, by default behaves the same way. As an example .. if you install CentOS-6.0 or RHEL-6.0 then at install time the ISOs contain similar versions (ie, the mysql versions and firefox versions offered at the same, etc.)

If you did this install during the 6.4 time frame, then did an update, you would get the updates from the 6.4/os tree and the 6.4/updates tree. This works the same way for both CentOS and the Default RHEL installs.

The problem that happens is that Red Hat also offers some subscription services called AUS, EUS, and ELS. ELS is Extended Lifetime Support which is something you can purchase after a products End Of Life is reached (you would need this to get any support or updates for RHEL-4 now). AUS seems to be longer life support for the "minor" branch (the .4 branch in 6.4), so in this subscription you would continue to get security updates for RHEL-6.4 even though RHEL-6.5 is released). Then there is EUS which seems to add a Z stream for 6.4 ... so a 6.4.1 and 6.4.2. I have no idea what its relationship is to 6.4 AUS ... that is beyond the scope of this mail and the CentOS project. (If you want to understand the nuances of RHEL subscriptions and the extended lifetime offerings in detail, contact the Red Hat sales team and they will gladly explain it in all its detail :) )

While we are not experts on what all of these Red Hat extended lifetime product acronyms mean and provide, they do all relate to the CentOS Linux distribution in exactly the same way. Red Hat does not now, nor have they ever provided those sources to the public, but only to the specific customers who are in those specific subscriptions. So, CentOS has never, and will never release these kinds of updates (unless Red Hat changes they way they release that source code).

Now to the problem. A CentOS minor version relates to a point in time snapshot of the all packages at a specific point in the lifetime of the major version. So that means that all 6.4 designates in the CentOS-6 distribution is that the "os/" directory of 6.4 matches the packages on the installable media that we produced on the date we built it and that it also matches the versions of software that is at that some point in time on Red Hat 6.4 ISOs. So, at the specific point in time, the distros are similar from a versioning perspective. All the non extended lifetime releases will go into our 6.4 updates directory and 6.4/os with 6.4/updates will have package versioning that is the same as the versions that are represented on this page for a given date range:

https://rhn.redhat.com/errata/rhel-server-6-errata.html

(Note: this is using the RHEL "Server" (v. 6) General Advisories .. we track everything in all the other "v .6" branches as well (Workstation, Desktop, HPC Node, Resilient Storage, High Availability, Load Balancer ... and FasTrack for each that have them)

But for explanation, lets just use the server page linked above. If you look at that linked page, Red Hat did a release of 6.4 on 2013-02-20 and they did a release of 6.5 on 2013-11-20. Our CentOS-6.4 release includes all versions of software on that page (our rebuilt software of course, not Red Hat software) that RH included on their ISOs up to the release point. Throughout the lifetime of our CentOS-6.4, all the updates that happened between those two dates went into our 6.4/updates directory. During the lifetime of 6.4, when it is on our main servers, if you yum update our product or RHEL if you would get similar versioning of your saftware packaging, etc. But when RHEL-6.5 happens, we start a new CentOS-6.5 tree. This is where there is confusion and what we are really trying to address ... Red Hat still has 6.4 AUS and 6.4.z EUS updates that they do ... and you can look at them here:

AUS: https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html

EUS: https://rhn.redhat.com/errata/rhel-server-6.4-errata.html

I know this is complicated ... but its important, so bear with me :)

So CentOS-6.4 stopped being supported when we released CentOS-6.5 ... we moved 6.4 to our vault. All the updates in the 6.4 channel stopped at that point and we started doing the new updaes into 6.5 .. our 6.5 "os/" is what is installable on the ISOs and our 6.5 updates (anything after 2013-11-20) is in the 6.5 "updates/" directory. But Red Hat still has not only their "v. 6" channel (which the CentOS versions are based on and are always up2date), but they also have those other two 6.4 channels (AUS an EUS).

Lets look at a security update ... the important OpenSSL one from 2014-06-05 ... if you look on the "rhel-server-6" above, it says this is the update that fixes the issue: https://rhn.redhat.com/errata/RHSA-2014-0625.html

That is version "openssl-1.0.1e-16.el6_5.14.src.rpm" ... Red Hat released that publicly, CentOS grabbed it, built it and put it in our 6.5 tree in the updates directory. If you are on our 6/ or 6.5/ tree, you got the update and all is well. If you are instead running CentOS-6.4 .. all is not well. You will never get that update. But, Red Hat has those other subscriptions ... AUS and EUS .. and those have this for 6.4: https://rhn.redhat.com/errata/RHSA-2014-0627.html

On that page, there are these available for 6.4:

AUS: openssl-1.0.0-27.el6_4.4.src.rpm EUS: openssl-1.0.0-27.el6_4.4.src.rpm

(in this case the same package)

But, Red Hat only gives out that package and its sources to customers that are in one of those "extended" subscription plans ... so therefore CentOS does not build that and we do not update our 6.4 directory on vault for this problem.

So, one major thing that the CentOS Project is trying to convey with this version number change recommendation is that CentOS is really Version 6 ... NOT version 6.4 and 6.5 ... and that we have snapshots in time of our tree to add newer hardware and software to the installer. But the only supported version of CentOS-6 is ever "the latest". We have said this many times, its in FAQs, on the mailing lists, etc. Regardless, people still think they can get security updates out of band (ie, 6.5 updates with 6.4 installed). We think that making the "Point In Time" (in this case, Date in the form of YYMM, since we will never have 2 releases in the same month) be the minor release number, instead of the RHEL minor version number, helps convey this concept and much better serves our users.

In my above example, if we were using the newly proposed numbering system, Red Hat would have 6.5, 6.4, 6.5 AUS, 6.5.z EUS, 6.4 AUS, 6.4.z EUS. There could be as many as 5 packages that would address the fix. CentOS on the other hand would have two releases ... 6.1302 and 6.1311 ... if your release is older than a year (normally even older than 9 months) then it is easy to tell (Feb 2013 is too old .. am I on the supported release). You can easily see that you are running a non supported tree. Also, 6.1311 would be the 5th listed version released, so if you were looking at a list, it would be number 5 on the list .. also traceable that way. But with the other Red Hat 6.4 offerings, we think that only causes confusion for CentOS users and we don't want that.

We think this system conveys exactly what we want to project with our versioning system. For CentOS-6 the releases would have been:

0. CentOS-6.1011 1. CentOS-6.1105 2. CentOS-6.1112 3. CentOS-6.1206 4. CentOS-6.1302 5. CentOS-6.1311

As you can see, the minor numbers also match in the list (6.3 matches 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 months between releases, etc.

Thoughts?

On 07/06/14 19:45, Akemi Yagi wrote:

As Trevor said, we just say, "CentOS 6.4 is no longer supported. Please update to 6.5". On the other hand, "CentOS-6.1302 is no longer supported. Please update to CentOS-6.1311 because it is June of 2014 today" sounds a bit cumbersome.

We also lose that 1:1 mapping with upstream where we're often asked "is CentOS 6.5 the same as RHEL 6.5".

Are you aiming to release new isos for every update? or every month? If not then I suggest we stick with the current naming convention as it fits better with the release of the media.

T

On Sat, Jun 07, 2014 at 07:52:07PM +0100, Trevor Hemsley wrote:

On 07/06/14 19:45, Akemi Yagi wrote:

...

As Trevor said, we just say, "CentOS 6.4 is no longer supported. Please update to 6.5". On the other hand, "CentOS-6.1302 is no longer supported. Please update to CentOS-6.1311 because it is June of 2014 today" sounds a bit cumbersome.

We also lose that 1:1 mapping with upstream where we're often asked "is CentOS 6.5 the same as RHEL 6.5".

Are you aiming to release new isos for every update? or every month? If not then I suggest we stick with the current naming convention as it fits better with the release of the media.

+1 for keeping the status quo. You've a decade of history maintaining the 1:1 mapping and it's what people expect. I realize that there are new requirements and constraints that the project must accommodate but something as core as this should remain consistent. In a followup post to this thread Trevor raises a good point in that it is hard enough to get people to update as it is; the dated versioning is going to make that even more difficult.

John

On Sun, Jun 08, 2014 at 12:22:34AM -0400, me@tdiehl.org wrote:

IMO, If you need something for the sigs, they should add it to their packages/repos and leave core the way has been since the beginning.

Especially since from the start it has been repeatedly stated that core will not change.

John

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Manuel Wolfshant Sent: 08 June 2014 08:40 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] CentOS 7 and release numbering

On 06/07/2014 09:45 PM, Akemi Yagi wrote:

...

On Sat, Jun 7, 2014 at 8:32 AM, Johnny Hughes johnny@centos.org wrote:

...

0. CentOS-6.1011
1. CentOS-6.1105
2. CentOS-6.1112
3. CentOS-6.1206
4. CentOS-6.1302
5. CentOS-6.1311

My worry is that if I phone into a support line of a commercial company who is supporting CentOS (such as IBM with TSM), they will be very familiar with their baseline support level of RHEL 6.4 (since this will be in their release notes as a pre-req). If we do not have an easy way to say that the CentOS release CentOS-6.1311 is equivalent, we will create some confusion.

Tim

On 07/06/14 19:45, Akemi Yagi wrote:

On Sat, Jun 7, 2014 at 8:32 AM, Johnny Hughes johnny@centos.org wrote:

...

0. CentOS-6.1011
1. CentOS-6.1105
2. CentOS-6.1112
3. CentOS-6.1206
4. CentOS-6.1302
5. CentOS-6.1311

As you can see, the minor numbers also match in the list (6.3 matches 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 months between releases, etc.

Thoughts?

After having read all the detailed explanations, I still do not see good enough justifications / rationale for changing the release naming.

The concept of 'supporting only the latest release' is quite simple and easy to explain to users. I don't think the current proposal would make it any easier. As Trevor said, we just say, "CentOS 6.4 is no longer supported. Please update to 6.5". On the other hand, "CentOS-6.1302 is no longer supported. Please update to CentOS-6.1311 because it is June of 2014 today" sounds a bit cumbersome.

My honest feelings...

Yet another +1

If a change is REQUIRED, that change should happen upstream in RHEL and then filter down to CentOS - i.e, if RHEL-7.1406 were to be released then a change to CentOS-7.1406 would make sense.

On 8 June 2014 17:37, Bryson Lee Bryson.Lee@sslmda.com wrote:

...

From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Ned Slider Sent: Sunday, June 08, 2014 5:41 AM

Yet another +1

If a change is REQUIRED, that change should happen upstream in RHEL and then filter down to CentOS - i.e, if RHEL-7.1406 were to be released then a change to CentOS-7.1406 would make sense.

+1 for staying aligned with upstream. "CentOS X.Y == RHEL X.Y" is easy to explain to management and corporate IT organizations that are hostile / risk-averse to open-source. Anything that requires more words / though and you're on the defensive and have lost the battle.

+1 from me. Bryson's comment, above, is very pertinent.

Show me that the current system is broken and I will agree to fixing it. "Fiddling" for the sake of "fiddling" is not required; after all RHEL (and thus CentOS) is *not* Fedora.

Alan.

This was already mentioned (kind of) but what is wrong with following:

Centos x.y-YYMM

This way you keep the current way and allow to create snapshots (one per month) It will not be confused with the .z branch from redhat either

Thanks Roger

Sent from Yahoo! Mail on Android

On 08.06.2014 14:40, Ned Slider wrote:

On 07/06/14 19:45, Akemi Yagi wrote:

...

On Sat, Jun 7, 2014 at 8:32 AM, Johnny Hughes johnny@centos.org wrote:

...

0. CentOS-6.1011
1. CentOS-6.1105
2. CentOS-6.1112
3. CentOS-6.1206
4. CentOS-6.1302
5. CentOS-6.1311

As you can see, the minor numbers also match in the list (6.3 matches 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 months between releases, etc.

Thoughts?

After having read all the detailed explanations, I still do not see good enough justifications / rationale for changing the release naming.

The concept of 'supporting only the latest release' is quite simple and easy to explain to users. I don't think the current proposal would make it any easier. As Trevor said, we just say, "CentOS 6.4 is no longer supported. Please update to 6.5". On the other hand, "CentOS-6.1302 is no longer supported. Please update to CentOS-6.1311 because it is June of 2014 today" sounds a bit cumbersome.

My honest feelings...

Yet another +1

If a change is REQUIRED, that change should happen upstream in RHEL and then filter down to CentOS - i.e, if RHEL-7.1406 were to be released then a change to CentOS-7.1406 would make sense.

+1 also from my side

In my opinion, the same version number as RHEL (upstream) is an integral part of CentOS.

Best regards,

Morten

Akemi Yagi skrev 2014-06-07 20:45:

On Sat, Jun 7, 2014 at 8:32 AM, Johnny Hughes johnny@centos.org wrote:

...

0. CentOS-6.1011
1. CentOS-6.1105
2. CentOS-6.1112
3. CentOS-6.1206
4. CentOS-6.1302
5. CentOS-6.1311

As you can see, the minor numbers also match in the list (6.3 matches 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 months between releases, etc.

Thoughts?

After having read all the detailed explanations, I still do not see good enough justifications / rationale for changing the release naming.

The concept of 'supporting only the latest release' is quite simple and easy to explain to users. I don't think the current proposal would make it any easier. As Trevor said, we just say, "CentOS 6.4 is no longer supported. Please update to 6.5". On the other hand, "CentOS-6.1302 is no longer supported. Please update to CentOS-6.1311 because it is June of 2014 today" sounds a bit cumbersome.

My honest feelings...

+1 as well - keep in line with upstream

/niklas

On 07/06/14 16:32, Johnny Hughes wrote:

<Snipidy Snip Snip Snapper Snap BOOM>

We think this system conveys exactly what we want to project with our versioning system. For CentOS-6 the releases would have been:

0. CentOS-6.1011
1. CentOS-6.1105
2. CentOS-6.1112
3. CentOS-6.1206
4. CentOS-6.1302
5. CentOS-6.1311

As you can see, the minor numbers also match in the list (6.3 matches 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 months between releases, etc.

Thoughts?

In my honest opinion, I can see your logic behind this however I feel this change would cause more harm than good.

First and foremost, If I have to ask an employee "What version of CentOS is that server on?"

A response of "It's on version six point five upgraded from six point four" tells me It's up to date and matches RHEL.

A response of "It's on version six point one one one two upgraded from six point one one zero five" makes me look at them with an odd face and does not immediately tell me if the machine is up to date as I would have to pull out a calendar and check dates to find the RHEL release that it matches.

Additionally, you may have confusion when it comes to international dates too because different countries have different date formats.

For example, in the UK we have the following format: Day-Month-Year, in the US the date format is: Year-Month-Day.

So some users may confuse 6.1311 as 6.<Month><Year> instead of what it actually is due to their local date format.

Essentially, that method of versioning would make it a pain in the other end.

I feel the solution to your problem is much simpler.

Let's say you have a SIG which is based on C6.5 the easiest way to allow people to know this is by versioning the SIG as follows:

<Signame> Version 6.5_1.3 (Or 6.5-1.3)

So it becomes:

<Signame> version <CentOS Version>_<Sig Version> (or <CV>-<SV>)

In this method, you are showing both version numbers and saving a whole lot of headaches.

If you over-complicate things then users will just get confused or old management will not be happy and end up complaining about admins talking gobbledegook about versions.

Although we normally don't care if management is happy or not but besides that's the point :-P (I'm the boss in our company so I can say that and get away with it, no one can sack me :-D)

Keeping versioning in-line with RHEL's versions is your best bet in my opinion. Naturally of course, if versions for SIGs have to be changed to be made more clear, then by all means proceed, but only change the SIGs versions, not the core's versions as otherwise it just causes confusion as the current versioning of core works just fine.

Anyhow, just putting my opinions in :-).

Kind Regards, Jake Shipton (JakeMS) GPG Key: 0xE3C31D8F GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F

On 06/08/2014 01:26 AM, Jim Perrin wrote:

...

I think that given the difficulty that we already have in persuading people to update to 6.$latest from 6.$prehistoric that produciing even more frequent variants is not such a good idea.

This is one of the reasons behind the idea of using dates. We could more easily show someone that what they were using was prehistoric because the date would be in their string. Do you think this would be more or less helpful on irc to be able to say something like "look, it says right in your release string that you're 2 years behind on updates"?

I think that it's just as easy to tell someone, "CentOS 6.1 is over two years old" in IRC, and I have yet to see anyone argue with that particular point. The usual argument is either "$boss|$company_policies won't let me me" or "$proprietary_app is not certified to run on any version newer than 6.1". Neither of those arguments will be helped by changing the version scheme, imo.

Maybe I'm missing something, but I honestly don't see how this will help SIGs, also I'm not entirely sure that it's the best course of action to put the needs of SIGs above the core value of maintaining RHEL compatibility. Also is this supposed need to help the SIGs theoretical or is it an actual problem that we are seeing now? Can the problem be spelled out in more detail and try to find a better way to tackle it as a community?

Probably needless to say at this point, but I tend to want to stay with the status quo, for whatever value my own opinion holds.

Peter

On 06/08/2014 05:12 PM, Brian Stinson wrote:

...

Maybe I'm missing something, but I honestly don't see how this will help

...

SIGs, also I'm not entirely sure that it's the best course of action to put the needs of SIGs above the core value of maintaining RHEL compatibility. Also is this supposed need to help the SIGs theoretical or is it an actual problem that we are seeing now? Can the problem be spelled out in more detail and try to find a better way to tackle it as a community?

+1 to maintaining the version numbers as they are. It's clear that the SIGs will add significant value to CentOS ecosystem, but they (IMHO) shouldn't supplant CentOS's primary asset: technical _and_ colloquial interoperability with RHEL. I think I understand the motivation for another versioning scheme, but surely there's a way to namespace everything such that it doesn't affect those who prefer the vanilla distribution.

I've read through the the responses so for and the main concern seems to be understanding the linkage between upstream and CentOS. Am I correct in that?

Carl.

On 8 June 2014 17:01, John R. Dennison jrd@gerdesas.com wrote:

On Sun, Jun 08, 2014 at 05:20:47PM -0400, Carl Trieloff wrote:

...

I've read through the the responses so for and the main concern seems to be understanding the linkage between upstream and CentOS. Am I correct in that?

That and the fact that it has been stated repeatedly that the CentOS core product will _not_ change and what is being discussed here is a change to that same core product.

Well I think this is more about defining what people think of as change and no change. Being the internet I am sure there are some set of people who will define any new release as being a change in the core product and thus a breakage. And there will be people who are at the other end of the spectrum and ok with all the change in the world as long as the name is CentOS and the first number is similar to the RHEL name. And then there are a ton of definitions of what is change and what isn't in between.

So a better discussion is I think people defining what they would accept as being 'change' and what is not change. The board has stated their view of change and various users are defining in a piecemeal way what is their definition of change. I think that it might be better if the users state a bit clearer so that the board has a definite idea of where the lines are.

On 06/09/2014 02:55 AM, Stephen John Smoogen wrote:

On 8 June 2014 17:01, John R. Dennison <jrd@gerdesas.com mailto:jrd@gerdesas.com> wrote:

On Sun, Jun 08, 2014 at 05:20:47PM -0400, Carl Trieloff wrote:
 >
 > I've read through the the responses so for and the main concern
seems to
 > be understanding the linkage between upstream and CentOS. Am I
correct
 > in that?

That and the fact that it has been stated repeatedly that the CentOS
core product will _not_ change and what is being discussed here is a
change to that same core product.

Well I think this is more about defining what people think of as change and no change. Being the internet I am sure there are some set of people who will define any new release as being a change in the core product and thus a breakage. And there will be people who are at the other end of the spectrum and ok with all the change in the world as long as the name is CentOS and the first number is similar to the RHEL name. And then there are a ton of definitions of what is change and what isn't in between.

So a better discussion is I think people defining what they would accept as being 'change' and what is not change. The board has stated their view of change and various users are defining in a piecemeal way what is their definition of change. I think that it might be better if the users state a bit clearer so that the board has a definite idea of where the lines are. -- Stephen J Smoogen.

I am main admin of the CentOS Facebook group. In about two weeks we will have 10.000 members. There are only 3 of us to properly respond, and we are on the frontline of newbie wave, those that never ever used IRC, forums or mailing lists. We have trouble just to explain that they need to upgrade to latest. Imagine the chaos that would come from date versioning. I think my ultimate response would be to just stop administering that group, period. Even now every 5-10 days I have to reiterate all basic steps even thou it is pinned in first post. People just do not read or learn anything they can get away with. They are lazy, and as it was previously said, every even small complication will repulse them away from CentOS.

AS for the "definition" of change, It was made simple by devel guys. There can not be no changes, beside most necessary, that distance CentOS from RHEL. What RHEL publishes CentOS must also publish, with only as minimal as possible changes. CentOS distro is not allowed to carry any 3rd party repo files because RHEL does not have them, and CentOS project strives to be binary compatible with RHEL.

And then suddenly, after CentOS Project members get payed by Red Hat CentOS project starts looking like Fedora respins, braking with RHEL numeration, CentOS distro becomes experimental platform for software Red Hat wants to push for better market share via respins, and we are left explaining to every single newbie why that had to be done.

If SiG's are going to be so problematic, then they can devise their own versioning scheme, because if they are going to create such difference from core CentOS distro then just call them CentOS-like distro's and be done with it. They are either CentOS with 3rd party repositories or will be just using SOME CentOS-produced packages for better use of available resources. Period.

On 2014-06-09 10:12, Ljubomir Ljubojevic wrote:

AS for the "definition" of change, It was made simple by devel guys. There can not be no changes, beside most necessary, that distance CentOS from RHEL. What RHEL publishes CentOS must also publish, with only as minimal as possible changes. CentOS distro is not allowed to carry any 3rd party repo files because RHEL does not have them, and CentOS project strives to be binary compatible with RHEL.

And then suddenly, after CentOS Project members get payed by Red Hat CentOS project starts looking like Fedora respins, braking with RHEL numeration, CentOS distro becomes experimental platform for software Red Hat wants to push for better market share via respins, and we are left explaining to every single newbie why that had to be done.

I think this is the core issue - we (users) have the belive that centos is redhat without support - and I would like to keep it that way - no extra 3rd party repo files etc - pure RHEL - same version, same software.

/niklas

On Mon, Jun 9, 2014, at 7:33, Jim Perrin wrote:

We're not talking about significant (or really even trivial) code changes here. We have no intention of breaking compatibility with 3rd party repos or software tied to a specific version with this. This is simply planning to avoid painting ourselves into a corner.

Please forgive the ignorance if I am missing something, but if there are no code changes what is the motivator for new release numbers? Are there concrete examples of what would change between monthly releases?

--Brian

On 09/06/14 15:33, Jim Perrin wrote:

On 06/09/2014 03:12 AM, Ljubomir Ljubojevic wrote:

<snip>

...

AS for the "definition" of change, It was made simple by devel guys. There can not be no changes, beside most necessary, that distance CentOS from RHEL. What RHEL publishes CentOS must also publish, with only as minimal as possible changes. CentOS distro is not allowed to carry any 3rd party repo files because RHEL does not have them, and CentOS project strives to be binary compatible with RHEL.

We're not talking about significant (or really even trivial) code changes here. We have no intention of breaking compatibility with 3rd party repos or software tied to a specific version with this. This is simply planning to avoid painting ourselves into a corner.

As an aside here, some of the sig work is specifically in response to what the community (and RH) is doing. Ami development, docker containers, xen etc all came about because of community/user demand. These days it simply isn't enough to just rebuild as we did in the past.

...

And then suddenly, after CentOS Project members get payed by Red Hat CentOS project starts looking like Fedora respins, braking with RHEL numeration, CentOS distro becomes experimental platform for software Red Hat wants to push for better market share via respins, and we are left explaining to every single newbie why that had to be done.

We were working on Xen4CentOS before any discussions with RH. RH providing (some of) us with a paycheck has simply meant we have more time to focus on the distribution instead of having late-night coffee-fueled work sessions after the family's gone to bed.

...

If SiG's are going to be so problematic, then they can devise their own versioning scheme, because if they are going to create such difference from core CentOS distro then just call them CentOS-like distro's and be done with it. They are either CentOS with 3rd party repositories or will be just using SOME CentOS-produced packages for better use of available resources. Period.

I want to see CentOS grow in usage and become much more widely adopted. That can't happen by ONLY doing the same things we've done for the last decade.

It's nice that the board has a vision Jim, but what can grow can also shrink too.

If we recall, it wasn't that long ago that the very continued existence / viability of CentOS was in question. Releases were delayed, security updates were slow to be released, bugs went unanswered. If community members questioned or asked when releases / security updates might be expected it was deemed as criticism and shot down in flames.

To the Project's immense credit, you guys have worked extremely hard to turn around that situation to the point where things now operate very smoothly and we almost expect updates to flow right out of the pipe within hours of an upstream release. To that end, the Project's future looks more stable (although I still know admins who were so concerned they switched to SL and have no intention of coming back).

But I think there still exists a perception of mistrust / suspicion within the community. I think there is concern that Red Hat might wish to dilute the notion that CentOS == RHEL - branding. Altering / changing something perceptually fundamental as the release numbering simply reinforces this notion at a time when many users are looking for the board to give assurances and build trust.

Maybe the board isn't feeling this? Maybe the board needs to slow down a little, listen to it's user base and earn it's trust? Maybe the board will just do as it pleases anyway?

On 09/06/14 18:21, Jim Perrin wrote:

On 06/09/2014 10:43 AM, Ned Slider wrote:

...

It's nice that the board has a vision Jim, but what can grow can also shrink too.

Indeed. In some areas, we already are. That's what we want to turn around. This is the fundamental reason why we can't simply rest and keep doing what we've been doing. Even if we're flawless in the core mission, we'd still be ignoring emerging areas where we must grow to survive.

...

If we recall, it wasn't that long ago that the very continued existence / viability of CentOS was in question. Releases were delayed, security updates were slow to be released, bugs went unanswered. If community members questioned or asked when releases / security updates might be expected it was deemed as criticism and shot down in flames.

Yep. we lost a fair number of both users and contributors.

...

To the Project's immense credit, you guys have worked extremely hard to turn around that situation to the point where things now operate very smoothly and we almost expect updates to flow right out of the pipe within hours of an upstream release. To that end, the Project's future looks more stable (although I still know admins who were so concerned they switched to SL and have no intention of coming back).

We burned bridges both on the way down, and on the way back up. This is 100% an accurate statement.

...

But I think there still exists a perception of mistrust / suspicion within the community. I think there is concern that Red Hat might wish to dilute the notion that CentOS == RHEL - branding. Altering / changing something perceptually fundamental as the release numbering simply reinforces this notion at a time when many users are looking for the board to give assurances and build trust.

In my view it's three separate perceptions that we have to fight.

1. Sins of the past. We historically haven't been great at working

publicly or with community input, as you mentioned in the beginning.

• In my eyes this amounts to broken trust, and it's difficult to fix.

This why we stood up seven.centos, and why we've tried to be as public as possible about what we're doing around the 7 build. It's why we've started holding our meetings in #centos-devel on irc as much as possible. We simply won't make everyone happy, but we can certainly be more transparent and open about how we operate.

2. That RH will try to force a change on us now that a significant chunk

of the board is being paid by RH.

For the sake of argument, lets just assume the worst about RH. Bought and paid for, we do their bidding and neuter CentOS. All that does is ruin RH's reputation. Users move to SL or another rebuild (if they don't jump to something else entirely) which refuses to collaborate now.

Reality: RH wants us to be more open. RH wants us to engage more with the community-at-large. They've given us a nice set of hardware upon which to create a community build system so that we can do these things without worrying that the donated machine we plopped down as the koji-hub won't up and vanish one night when the donor reclaims it. We've simply spotted something that will likely cause us issues as we grow, and we want the community to help us shape how we resolve it ahead of time so we're not stuck later.

3. That we're *just* a downstream.

Again, historical perceptions that haven't been entirely accurate. We've been doing some of our own thing for years, with limited resources and limited success. The centosplus kernel, our own updated php versions or postfix-with-mysql packages, Xen4CentOS, etc.

With dedicated time and more available resources, we're able to explore this further (and hopefully better). We know there are integrators using centos as a platform. We're trying to connect with them, to see if there's value in collaboration.

This work may or may not go back to RH, but that doesn't matter if it helps our community. If our users want it and are willing to help make it happen then that's what counts.

...

Maybe the board isn't feeling this? Maybe the board needs to slow down a little, listen to it's user base and earn it's trust? Maybe the board will just do as it pleases anyway?

We are feeling it, and we are listening, but our views may not always align. In some cases, our users are looking at their own needs, and not at the larger distro picture.

In other cases, we're only hearing the ones who take the time to talk to us. So if there's a very vocal 10%... that may or may not line up with the other 90% who remain silent wondering wtf we're thinking.

You're correct though. We do need to continue to earn and maintain the community's trust. It may be coming from a .mil mentality, but my thinking has always been to earn it by action. I've said before that we need to SHOW the community the things we've been talking about since the RH announcement so that it's more than just words. But you bring up a valid point in that we need to listen as well.

It's difficult to argue with you when you state your case that well, so lets move forward :-)

To that end, help us discuss an appropriate solution for this.

To do that I'm going to need a better understanding of the technical problem you are trying to solve. Can you spell it out for me in terms I can understand, maybe with hypothetical examples of what you envisage, because TBH I read the proposal and didn't see anything there that I felt warranted making such a perceptually important (at least to me) decision to completely change the long-established product numbering.

Perhaps I can quote the original proposal and reply inline:

"As we approach the release of CentOS 7, the CentOS project board has been discussing making a change to the way that we name individual CentOS Linux releases. We've always just adopted the X.y numbering, but it's clear to us that as we build up the SIG efforts, we need to find a way to allow SIGs producing variants the ability to stay in sync with their own upstream timelines, while ensuring that it's always possible to track back to the release of CentOS Linux they built or deviated from."

Presumably they would always build or deviate from the latest release plus updates, as that's always going to be the only thing that is ever supported. Looking at the build dates will tell you exactly when it was built. A release date on the website/wiki next to the download link works for that.

"We've been discussing a new versioning scheme in which we'd keep the major version number from upstream, and append a Year/Month value reflecting when the corresponding RHEL (or interim CentOS) release shipped. So, if RHEL 7 came out this July, the version name would be CentOS 7.1407. We also feel this better reflects to users the age of the install."

Sounds like change for change sake. I don't see the technical problem you're trying to solve nor how this would solve it.

"A change like this would allow CentOS to continue to deliver the core distribution (a Red Hat Enterprise Linux rebuild) while allowing ourselves the flexibility to roll in additional enhancements, such as optional repos and configuration choices included in our installer, with the goal of growing our commnuity base by delivering value to users and promoting the work of SIGs."

How does changing the version specifically permit or prohibit any of this. You can roll in all of the above changes regardless of whether you call it CentOS 7.0 or CentOS 7.1407. It's just a number, albeit a very significant one.

"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.

Could you not simply introduce some new virtual package "centos-version-snapshot-7.1407-1.el7" with whatever other virtual provides you may require that you bump each time you rebuild to achieve whatever it is you want to achieve? Heck, you could call it "centos-version-snapshot-7.140701-1.el7" and auto-rebuild it every day if you want so you really have an accurate point in time for any deviants.

Karanbir,

So far, the community input seems to be strongly in favour of keeping the x.y conventions (potentially adding a timestamp for areas such as cloud images).

Among our user community, a change to timestamp only would cause significant confusion. We do not have the opportunity to explain at length that YYMM is compatible with y and that there is a web page giving the mapping between versions.

I am not yet seeing major enough benefits to make such a change, especially at this point of transition of the community in view of the downstream difficulties it will cause for those of us supporting large user bases where these conventions are well established.

Tim

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Karanbir Singh Sent: 10 June 2014 13:09 To: centos-devel@centos.org Subject: Re: [CentOS-devel] CentOS 7 and release numbering

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 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On 06/10/2014 05:21 AM, Jim Perrin wrote:

Indeed. In some areas, we already are. That's what we want to turn around. This is the fundamental reason why we can't simply rest and keep doing what we've been doing. Even if we're flawless in the core mission, we'd still be ignoring emerging areas where we must grow to survive.

I don't think I've seen anyone argue against SIGs here. I think most people on this list understand the importance of SIGs to CentOS and the future that CentOS will have with them. What I see is many people here saying that SIGs should not dictate the direction of the core OS, that needs to remain pure to upstream.

In my view it's three separate perceptions that we have to fight.

1. Sins of the past. We historically haven't been great at working

publicly or with community input, as you mentioned in the beginning.

• In my eyes this amounts to broken trust, and it's difficult to fix.

This why we stood up seven.centos, and why we've tried to be as public as possible about what we're doing around the 7 build. It's why we've started holding our meetings in #centos-devel on irc as much as possible. We simply won't make everyone happy, but we can certainly be more transparent and open about how we operate.

Well in reading through this thread it seems to me that the community is overwhelmingly *against* this change. In fact the only people who I have seen argue for it are the core devs. If you want to be more open to the community then that's a two way street, you need to not only be more transparent, but also be more willing to listen to the feedback you get from the community. You speak of mending "broken trust" and to fail to listen to such overwhelming feedback from the community would be counterproductive to that effort.

To that end, help us discuss an appropriate solution for this.

Please (re-)state the actual problem we're trying to solve here. As others have pointed out, this seems to have been glanced over in the push to present this "solution".

Peter

On 06/10/2014 12:33 AM, Johnny Hughes wrote:

On 06/09/2014 04:05 PM, Peter wrote:

...

On 06/10/2014 05:21 AM, Jim Perrin wrote:

...

Indeed. In some areas, we already are. That's what we want to turn around. This is the fundamental reason why we can't simply rest and keep doing what we've been doing. Even if we're flawless in the core mission, we'd still be ignoring emerging areas where we must grow to survive.

I don't think I've seen anyone argue against SIGs here. I think most people on this list understand the importance of SIGs to CentOS and the future that CentOS will have with them. What I see is many people here saying that SIGs should not dictate the direction of the core OS, that needs to remain pure to upstream.

No one is saying that anything in the Core OS is changing ... the Core OS will be the Core OS. It will be ONLY packages in the RHEL tree and it will not contain anything extra. That is not the issue here. The issue is, people think they can run CentOS-6.4 after 6.5 is released and it is the same as running RHEL-6.4 AUS/EUS ... and its not. Our numbering is not like their numbering and that is causing massive confusion that we need to fix. One can absolutely, positively not stay behind and have security. It is very dangerous.

Add to that the fact that the SIGs also may need to have a new installer be created between RHEL releases, so we may (or may not ... only time will tell) need to create some new install trees.

None of that adds packages into the os/ or updates/ directory that is not in RHEL ... that will be the same and people will have to opt-in to get anything that is not Core .. just like they do now.

<snip>

So far solution was: "To be on the latest version, please run 'yum update -y'".

If someone needs to stop on certain version, that person is most likely already a professional with an understanding. Solution to stay on CentOS 6.4 is to provide /6.4/updates repository next to /6.4/os. And maybe provide release package for all minor version, if admin of such system is not smart enough to change it by hand.

But to wreak havoc on unsuspecting newbies that we all are trying to attract, not chase away. And that havoc will spill out to people doing support, for CentOS users not ready to ditch it but unable to comprehend/track changes.

What about keeping 6.5 versioning but also releasing 6.201406 kind of ISO respins (with modified release packages?)?

I am also trying to understand which case scenario would demand such drastic change. Negative aspects are so many, but I can not comprehend what could possible be positive ones. So give us real world examples of what you thing would be a problem, convince us this change is needed.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 06/10/2014 10:33 AM, Johnny Hughes wrote:

No one is saying that anything in the Core OS is changing

Except the version scheme.

The issue is, people think they can run CentOS-6.4 after 6.5 is released and it is the same as running RHEL-6.4 AUS/EUS ... and its not.

No, it's the same as running RHEL without AUS or EUS.

Our numbering is not like their numbering and that is causing massive confusion that we need to fix. One can absolutely, positively not stay behind and have security. It is very dangerous.

Believe me, I understand where you're coming from, I see the same people day in and day out come into IRC that you see who are on some old version of CentOS and think that's fine. But inevitably, their issue is not that they ever thought that the version they were on is still getting updates, because inevitably they are not updating at all otherwise they would be on the most recent CentOS version. It is absolutely wrong to think that changing the version scheme will address this in any way, it simply won't because those types of people have no concept about keeping their OS up to date regardless of what the version string is.

And just because you change to a date-based version absolutely does not tell anyone that the older "dates" are EOL. People will see this as being no different to distros such as Ubuntu (forgive me $DEITY) which uses date-based versions, but still has new releases every six months and any given release is supported for a minimum of two years up to five years for their LTS releases, so you could be on Ubuntu 10.04 and it is still current and supported, what's to stop people from equating the CentOS dates to this and thinking, "CentOS has a 10 year lifespan so my CentOS 6.1312 release should be good until December of 2023"?

Granted the above is unlikely but just as much is the idea that someone will think that their release of CentOS is expired just based on a YYMM release date. All it is is making a completely unrelated change with wishful thinking that people who don't know to update or understand why they should have to will be any more likely to update because you make some crazy change to the version scheme.

Add to that the fact that the SIGs also may need to have a new installer be created between RHEL releases, so we may (or may not ... only time will tell) need to create some new install trees.

I will re-iterate here that you are making changes to the core to accommodate SIGs, changes that you haven't even demonstrated a legitimate need for. The issue with the SIGs can be addressed with versioning that would be specific to the SIGs and then not have to push their needs onto the core distro.

None of that adds packages into the os/ or updates/ directory that is not in RHEL ... that will be the same and people will have to opt-in to get anything that is not Core .. just like they do now.

No but it will make subtle changes to key files in core packages that could cause compatibility issues with 3rd-party software. I have already described how this can happen and to me that is certainly a deviation from RHEL that should not be dismissed.

Peter

Hi,

On 06/18/2014 06:02 PM, Akemi Yagi wrote:

With the release of CentOS 7 just around the corner, have the board members made a decision?

No we havent, its something we've been iterating over but there is no decision made at this point.

We have seen an overwhelming number of responses from the community members. Many of them are long time contributors who do not mind "having late-night coffee-fueled work sessions after the family's gone to bed".

Now the world is watching (between the FIFA games) how the board would handle the situation in which their idea/plan does not get support from the community.

So, personally - I think the community feedback was great, how badly we communcated the idea was apareny and clear for everyone to see. And I personally feel that a large chunk of the response was down to fear of change in areas that we had never even imaged were going to change.

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

So what it really boils down to is communication, and not technical reasons as to why there is resistance to this change. And if we are able to find a clear / clean way to communicate the relationship - something that the community at large agree's to, then we have a plan going forward.

I seem to be saying this a lot, but getting better at what we do should never really be optional - and I definitely feel that the numbering change allows us to do just that. We just need to find a way to to communicate and overcome the emotional resitance to change. CentOS Linux is going to always retain RHEL mapping for 1:1 rebuild, as a best effort - and now more open and more visible than before. Now, reparse the thread with that statement in mind and you will find that the biggest resistance goes away completely.

How can we make it even more aparent as to what we are trying to do ?

I will aim to deliver two sets of tree's today to buildlogs.centos.org, one that targets a 7.0 release tag and another one that does 7.1406, lets see if we can find, in using the 7.1406 metrics on what breaks and how. We can then work backwards to fix the issues, and move the conversation forward.

<plug>Also, I've been working flat out 15hrs/day for the last 4 weeks to get us here - if anyone was hoping to come along and join the contributor path, please dont hold back :) </plug>

- KB

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Greg Lindahl Sent: 20 June 2014 12:53 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] CentOS 7 and release numbering

On Fri, Jun 20, 2014 at 11:35:08AM +0100, Karanbir Singh wrote:

...

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

I read it, and I'm still 'meh' on the concept. I think that there should be a compelling reason to diverge from upstream versioning, and I don't see it.

The SIG problem is that either SIGs are at the tip, or not. Having different version names from upstream doesn't really help.

The user problem is that either users are at the tip, or not. Having different version names might make that more obvious, but I bet that people who don't stay at the tip won't notice.

I stay at the tip. Having different version numbers from upstream merely confuses my coworkers. Hence, 'meh'.

-- greg

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

I share Greg's perspective. I see the technical arguments but have not seen the benefits that justify the significant confusion.

The communication problems you raise are exactly the ones that we will have with our user community. Given the difficulties you have explaining it to those on centos-devel, imagine how we'll be explaining it to our thousands of users, external support lines and management chains.

I could explain a 7.0 or even 7.0.1406 but a 7.1406 with an associated wiki page would cause us real problems in the field.

Tim

On 06/20/2014 02:15 PM, Johnny Hughes wrote:

On 06/20/2014 06:06 AM, Tim Bell wrote:

...

...

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Greg Lindahl Sent: 20 June 2014 12:53 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] CentOS 7 and release numbering

On Fri, Jun 20, 2014 at 11:35:08AM +0100, Karanbir Singh wrote:

...

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

I read it, and I'm still 'meh' on the concept. I think that there should be a compelling reason to diverge from upstream versioning, and I don't see it.

The SIG problem is that either SIGs are at the tip, or not. Having different version names from upstream doesn't really help.

The user problem is that either users are at the tip, or not. Having different version names might make that more obvious, but I bet that people who don't stay at the tip won't notice.

I stay at the tip. Having different version numbers from upstream merely confuses my coworkers. Hence, 'meh'.

-- greg

I share Greg's perspective. I see the technical arguments but have not seen the benefits that justify the significant confusion.

The communication problems you raise are exactly the ones that we will have with our user community. Given the difficulties you have explaining it to those on centos-devel, imagine how we'll be explaining it to our thousands of users, external support lines and management chains.

I could explain a 7.0 or even 7.0.1406 but a 7.1406 with an associated wiki page would cause us real problems in the field.

You think it is much easier to explain a data breach costing your client in the field millions dollars because someone THOUGHT they had 7.1 EUS and all its security updates, just like RHEL has, when the tree is at 7.3? We need to prevent people from thinking is OK to stay on an old tree, it absolutely is not.

adding mere digits to the name will not help in any way. as far as I have seen in #centos, most of those who do not update stay at a particular version in time because they do do not WANT to update not because they are not familiar with the concept or the need to update. "it works as it is, we are afrain that an update might break something". what most are not familiar with are unchanged ABI and backports. But changing the naming scheme will not help with that in any way.

On 06/20/2014 02:43 PM, Karanbir Singh wrote:

On 06/20/2014 12:23 PM, Manuel Wolfshant wrote:

...

adding mere digits to the name will not help in any way. as far as I have seen in #centos, most of those who do not update stay at a particular version in time because they do do not WANT to update not because they are not familiar with the concept or the need to update. "it works as it is, we are afrain that an update might break something". what most are not familiar with are unchanged ABI and backports. But changing the naming scheme will not help with that in any way.

but focusing on the /7/ would be .. also, lots of people drop into #centos running 6.2 or 5.6 because they were not aware that they were too far adrift. Switching the focus to CentOS-7 cant possibly cause more confusion.

I\indeed, switching the focus to CentOS-7 cant cause more confusion. Switching to "you should update to centos 7-20140620 because you have 7-20140501 " would. As i have already said earlier, those who do not update stay at a particular version in time because they do do not WANT to update not because they are not familiar with the concept or the need to update. Or maybe, as trevor put it, they do not know that they should update. In both cases the time field will be as useless as the minor release field is now so no benefit would be added.

On 06/20/2014 06:23 AM, Manuel Wolfshant wrote:

On 06/20/2014 02:15 PM, Johnny Hughes wrote:

...

On 06/20/2014 06:06 AM, Tim Bell wrote:

...

...

-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Greg Lindahl Sent: 20 June 2014 12:53 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] CentOS 7 and release numbering

On Fri, Jun 20, 2014 at 11:35:08AM +0100, Karanbir Singh wrote:

...

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

I read it, and I'm still 'meh' on the concept. I think that there should be a compelling reason to diverge from upstream versioning, and I don't see it.

The SIG problem is that either SIGs are at the tip, or not. Having different version names from upstream doesn't really help.

The user problem is that either users are at the tip, or not. Having different version names might make that more obvious, but I bet that people who don't stay at the tip won't notice.

I stay at the tip. Having different version numbers from upstream merely confuses my coworkers. Hence, 'meh'.

-- greg

I share Greg's perspective. I see the technical arguments but have not seen the benefits that justify the significant confusion.

The communication problems you raise are exactly the ones that we will have with our user community. Given the difficulties you have explaining it to those on centos-devel, imagine how we'll be explaining it to our thousands of users, external support lines and management chains.

I could explain a 7.0 or even 7.0.1406 but a 7.1406 with an associated wiki page would cause us real problems in the field.

You think it is much easier to explain a data breach costing your client in the field millions dollars because someone THOUGHT they had 7.1 EUS and all its security updates, just like RHEL has, when the tree is at 7.3? We need to prevent people from thinking is OK to stay on an old tree, it absolutely is not.

adding mere digits to the name will not help in any way. as far as I have seen in #centos, most of those who do not update stay at a particular version in time because they do do not WANT to update not because they are not familiar with the concept or the need to update. "it works as it is, we are afrain that an update might break something". what most are not familiar with are unchanged ABI and backports. But changing the naming scheme will not help with that in any way.

I'll try to explain this in a different way.

The goal that we have, and have always had, in CentOS is rebuilding the RHEL Sources and maintaining bug for bug complete compatibly with a specific RHEL branch. That specific RHEL branch is the MAJOR branch. Major being el3, el4, el5, el6, el7, etc.

When RHEL first started doing updated branches, they had one branch and they did updates to it .. they called it RHEL 3 and the updates were RHEL 3 update 3. We (the CentOS Project) called it 3.3. The dot or point release signified a point in time release and was not to be used in any way other than to signify at that exact point in time, we had some relation to the upstream source code.

As you can see, in that case we were PURPOSELY different from RHEL's numbering .. because RHEL was doing other things besides just the update 3 in their 3 branch. We did not want to confuse our users into thinking we were doing all the things in the 3 branch ... we were doing one thing and doing that one thing well ... maintaining a el3 tree.

Red Hat then changed and adopted OUR numbering scheme for RHEL.

The fact of the matter is, that our point releases are NOT the same as the RHEL point releases ... they are doing much more things inside the point release trees than we are (now, just like before).

It seems ALL our users are confused and think our releases have a complete and ironclad direct relationship to the exact point release upstream .. they have the same number, they must be the same, right?

The issue here is that they are not the same and we (the CentOS Project) have an obligation to communicate that to our users. Our updates are just a point in time snapshot of the main line MAJOR tree ... that is what they are now and what they always have been. It is all about the /7/ and not about the point.

What better way to communicate that they are not standalone but are all only part of the MAJOR release and a POINT IN TIME part of that major release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?

Johnny Hughes wrote:

What better way to communicate that they are not standalone but are all only part of the MAJOR release and a POINT IN TIME part of that major release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?

The current scheme represents <POINT IN TIME> as an integer that starts from zero and increments with each minor release.

I remain unconvinced that a YYMM representation of <POINT IN TIME> is any better.

Ron

Once again If the goal is to point to the fact centos 6.4 is different than rhel6.4 after 6.5 is out, then make something right when the differentiation start and not before You can release a new centos release package for 6.4 or you can do something on the repo, that make it clear to client, that something changed and updates do not work anymore unless the SA does some concious local change to make it not complain again, will that break some auto update on those clientes? Yes, but that would be desired to make it clear that something is requiered from the local SA in order to keep the box secure

But, I still see a big plus by having a release like mayor.minor.date, it is more flexible without breaking the old way , both side wins because a client could see/notice that their 7.0.x is too old when it was getting refreshed every now and then (asuming there will be respins more oftens that rh releases)

Ok, let me go further in a mental exercise, let say we make the change proposed and the .minor number is changed to .date of release. Lets imaging a year from that release there is serious vulnerability that put the world to check "am I vulnerable?". Manager or lazy SA check that we are running 7.20140701, they are not familiar with, they might even remember that was created when rhel7.0 was released but to be sure they go to a wiki and confirm that indeed that release of centos is the rebuild of rhel7.0 but they probably also notice that there are newer resping of centos based on newer releases of rhel, and probably they might notice that what they are running is no supported anymore raising more questions to them. What this might have different if we keep things as they are right now ? Probably because of what you are saying , that hypotetical person might hope/expect/ that centos is also following what redhat is doing and a fix will come in there way but at that point updates will not work unless conciously a manual change was performed and a the only update available might be a new centos release saying it is not supported

Make sense ? Again, having major.minor.date format looks like a compromise that have the best of both worlds

Thank roger

Sent from Yahoo! Mail on Android

On 06/21/2014 03:47 PM, Ljubomir Ljubojevic wrote:

On 06/21/2014 03:31 PM, Roger Pena Escobio wrote:

...

Once again If the goal is to point to the fact centos 6.4 is different than rhel6.4 after 6.5 is out, then make something right when the differentiation start and not before You can release a new centos release package for 6.4 or you can do something on the repo, that make it clear to client, that something changed and updates do not work anymore unless the SA does some concious local change to make it not complain again, will that break some auto update on those clientes? Yes, but that would be desired to make it clear that something is requiered from the local SA in order to keep the box secure

But, I still see a big plus by having a release like mayor.minor.date, it is more flexible without breaking the old way , both side wins because a client could see/notice that their 7.0.x is too old when it was getting refreshed every now and then (asuming there will be respins more oftens that rh releases)

Ok, let me go further in a mental exercise, let say we make the change proposed and the .minor number is changed to .date of release. Lets imaging a year from that release there is serious vulnerability that put the world to check "am I vulnerable?". Manager or lazy SA check that we are running 7.20140701, they are not familiar with, they might even remember that was created when rhel7.0 was released but to be sure they go to a wiki and confirm that indeed that release of centos is the rebuild of rhel7.0 but they probably also notice that there are newer resping of centos based on newer releases of rhel, and probably they might notice that what they are running is no supported anymore raising more questions to them. What this might have different if we keep things as they are right now ? Probably because of what you are saying , that hypotetical person might hope/expect/ that centos is also following what redhat is doing and a fix will come in there way but at that point updates will not work unless conciously a manual change was performed and a the only update available might be a new centos release saying it is not supported

Make sense ? Again, having major.minor.date format looks like a compromise that have the best of both worlds

Thank roger

Sent from Yahoo! Mail on Android

---

*From: * Johnny Hughes johnny@centos.org; *To: * centos-devel@centos.org; *Subject: * Re: [CentOS-devel] CentOS 7 and release numbering *Sent: * Sat, Jun 21, 2014 10:42:26 AM

On 06/21/2014 05:00 AM, Ron Yorston wrote:

...

Johnny Hughes wrote:

...

What better way to communicate that they are not standalone but are all only part of the MAJOR release and a POINT IN TIME part of that major release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?

The current scheme represents <POINT IN TIME> as an integer that starts from zero and increments with each minor release.

I remain unconvinced that a YYMM representation of <POINT IN TIME> is any better.

It is not really better at conveying time, no. It is the same at conveying the time.

Where it is better is in denoting that Red Hat is doing things inside the 6.4 tree (again, just following the above example) while CentOS does not do those things inside our 6.4 tree after we release 6.5. We can't do them, even if we want to as we don't have the sources.

That is my whole point .. we need a way to convey a similarity and one point, while not being similar always. Having the exact same name does not convey that.

How do you suggest we do that and not ignore that there are potential differences after we move to the next point release? Do we just ignore that part?

Everything on this list that is newer than 2013-11-20 is in the RHEL 6.4 tree ... we don't and can't release any of it for our 6.4:

https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html

So our 6.4 tree is now significantly divergent from the Red Hat 6.4 tree, and our 6.4 tree is in the vault and not live anymore ... don't we have an obligation to our users to make sure they understand that there are differences?

UserA has some software that only works with 6.4 .. he sees CentOS-6.4 in the vault and grabs that to use with his software. He can't upgrade to 6.5 because it will break his software. Staying on our 6.4 tree will leave UserA vulnerable with security issues. If he is instead on the Red Hat 6.4 tree, he is still going to be able to get updates. Do we not have any obligation to change our numbering so that UserA can more easily tell this hugely major difference?

We don't really have the upstream point releases, we have different point releases. We release the main line CentOS-5, CentOS-6, and CentOS-7 ... we do point in time respins of ISOs and install trees, Red Hat does all this and a bunch more things also inside point releases. These two things are not EXACTLY the same ever, but they are very similar for one 6 to 8 month "period of time" (while they are OUR active release and Red Hat's active release) and they become increasing divergent after that point in time. That is what I am trying to convey here. Some people will argue that people have to pay for that other REd Hat 6.4 tree ... sure they do. They also have to pay the initial Red Hat 6.4 tree, they have to pay for everything there, thats how it works.

Everyone here thinks that we should just leave the point releases as is, knowing that now Red Hat is doing completely different things inside point releases and that we don't have an obligation to point out the differences?

I "yum update" moves you to newer version, then it is all the SAME as today. Updating WILL update that system beyond support.

If we need to reproduce point-in-time releases, then lets create base + updates repositories for every minor release (6.4 for example) and update it with only security fixes.

If we do not want to change the way CentOS is updated, then all we are saying to people is "We do not WANT to be same as RHEL, so if you want RHEL then buy it" which will brake a trust people have in CentOS binary compatibility with RHEL.

Just to emphasize, people want COMPATIBILITY with RHEL, that is why we use it. If there will be no PERCEIVED compatibility, people will start waling away from CentOS. As simple as that.

On 06/21/2014 06:56 PM, Johnny Hughes wrote:

...

Just to emphasize, people want COMPATIBILITY with RHEL, that is why we use it. If there will be no PERCEIVED compatibility, people will start waling away from CentOS. As simple as that.

And the CentOS goal is full functional compatibility.

We do now have and will continue to have that.

Changing a number in the name does not impact that at all ... it just means we are trying to better describe what CentOS is.

That IS the point over board and users are arguing about. Just like "Beauty is in the eye of the beholder", so is the "truth" what something is or isn't. All of users are trying to PRESERVE what was established. We do not think CentOS should be redefined just because of minority that uses apps that are meant for certain point-in-time.

So if you choose to keep with this PR nightmare, be ready to have diminishing membership, instead of increasing it. That is at least what vast majority of us, majority of community, on this list think. If you were to conduct referendum on this issue, I think 99% of CentOS users would vote against.

And then, to the all that follow this, it would look like selected few, now on the payroll of company that has vested interest in future of CentOS distro/project will go against will of vast majority of projects community, and play in the hand of that same company and it's profits.

While we are at it, why is Red Hat owner of "centos.org" domain name? And why is the Red Hat owner of CentOS trademark? "The CentOS Project is a community project. The CentOS Project leadership has transferred the CentOS trademark to Red Hat for protection and stewardship. The CentOS Governing Board will be responsible for policing use of the mark."

Who voted on it? Larger Community hasn't.

In fact, up to this point I thought CentOS is just joining forces with Red Hat. But text of the announcement says "The new initiative is going to be overseen by the new CentOS Governing Board." So this is actually NEW project that will claim CentOS name, but will not continue as CentOS, but in fat will be OpenRHEL. Only when I put together 2 and 2, Boards intention to remove OpenRHEL from CentOS that existed until January did I understood that my arbitrary story about what might happen is actually right.

Whois on centos.org:

Registrant Contact Information: Name: Red Hat, Inc. Organization: Red Hat, Inc. Address 1: 100 East Davie Street City: Raleigh State: NC Zip: 27601 Country: US Phone: +1.9197543700 Fax: +1.9197543704 Email: Email Masking Image@redhat.com

Administrative Contact Information: Name: Domain Admin Organization: Red Hat, Inc. Address 1: 1801 Varsity Drive City: Raleigh State: NC Zip: 27606 Country: US Phone: +1.9197543700 Fax: +1.9197543704 Email: Email Masking Image@redhat.com

Technical Contact Information: Name: Domain Admin Organization: Red Hat, Inc. Address 1: 100 East Davie Street City: Raleigh State: NC Zip: 27601 Country: US Phone: +1.9197543700 Fax: +1.9197543704 Email: Email Masking Image@redhat.com

In light of this new revelation, if you go on with the change, count me out of any further contributing. I will continue to use it, but will welcome any attempt to restore old CentOS even under some other name.

Am 22.06.2014 17:53, schrieb Johnny Hughes:

All we are trying to do here is be completely honest and complete open about the distro as a whole and the process to get it as a whole. So now everything is open, you can see everything about it all, and a number after the decimal point in the name and/or the difference in the word Binary and Functional is enough to make you mistrust something that you have been using for free for ten years?

Johnny, Karanbir

I take it like Alain - <MAJORRELEASE>.<POINT IN TIME> seems a good choice (as I never did bother with the various subscription options for RH). You guys have my vote of trust as well, as long as 'yum update' does the trick :)

Cheers Christoph

It's amazing how quickly people trot out conspiracy theories when the stuff they're getting for free might be free but slightly different.

I haven't weighed in on this thread-o'-doom yet, and I was hoping not to, but it has simply jumped the fucking shark. If you're really that concerned about our new Red Hat overlords, I'd like to make two suggestions:

1. Fedora is coming up on its 21st release, which, at one every six months (roughly), comes out to over a decade of free, community Linux. During that entire time Fedora has been in bed, to a substantial degree, with Red Hat. (Note that I use the non-legal metaphor "in bed" instead of risking some petty bullshit semantic quibble over whether they're "led by" or "owned by" or whatever. They're sleeping together, okay?) And during that entire time, great bearded prophets of doom have emerged from the desert to proclaim that Fedora N-1 was surely the last free and open Fedora because the crushing hand of Genghis Red Hat is squeezing everything good out of it. I'd wager a beer (and this is a serious offer) that every single Fedora release after Fedora Core 1 has had at least one such Chicken Little. Take a browse through their various mailing lists.

Luckily, CentOS will have its Sandy Hook deniers right from its first release after knocking boots with Red Hat.

Maybe Red Hat is just completely fucking incompetent at corporate takeovers of community projects. Maybe they aren't even trying to take over Fedora or CentOS. Maybe they already have and we're all living in The Matrix brought to you by Red Hat and we don't even know it. Draw your own conclusions.

2. Absolutely nothing is stopping anyone -- including experienced rebuilders like the SL folks -- from building their own OMG MOAR OPEN rebuild. Nothing. In fact, git.centos.org makes it *easier*, because we have changelogs and historical sources and shit like that, not just a bunch of SRPMs that represent the current state of the repo. If RH really wanted to undermine community rebuilds and prevent them from challenging their market supremacy, they sure as hell would. For instance, I bet a clever lawyer could make a compelling case that RH only needs to release the sources, not the specfiles. And they don't have to release their source modifications at all for many of the more permissive FOSS licenses. They could royally fuck everyone who runs a free clone if that was their schtick.

Again, draw your own conclusions. Maybe RH is just incompetent.

Then again, maybe we've got a zillion-post thread with an SNR that's indistinguishable from zero because:

1. CentOS is now *more* open than ever, and rather than just making this change they're soliciting community involvement. Which is good. (And they seem to be listening to the need to reflect the RH minor version in the CentOS release version, too.)

2. Some people can't cope with change. When I was in .edu we used to tell this joke:

Q: How many professors does it take to change a lightbulb?

A: *CHANGE*?!?!?

Oh noes, RH decided to change the way they give away mountains of work that they're not required to!

Oh noes, several the CentOS core devs (who had employers before -- you know that, right? and those employers surely expected value from their investment then -- you know that, too, right?) now work for RH!

Oh noes, there's occasionally a point of disagreement between people who use CentOS for a living and those who build it for a living! (Maybe they're two very different constituencies with different goals? Nah, that's absurd!)

3. Any sufficiently large community is bound to have a few of the kind of screw-loose types who think the moon landing happened on a Hollywood sound stage. I mean, the CentOS folks have gone to great lengths at several points to belabor the fact that they really don't have a very special relationship with RHEL. (That's RHEL, not RH.) They pull their sources from git.centos.org one leg at a time, just like the rest of us, for instance. That certainly doesn't bespeak much of a vast Red conspiracy to overthrow the world. But I guess belief in this conspiracy already hinges upon the absolute incompetence of most of the players.

Ultimately, we as community members have three options. I'll spare you another numbered list, because they're short: We can just flow like seaweed in the tide and take whatever comes our way, which is pretty unlikely given that most us are antisocial nerds; we can continue to contribute *productively* and try to guide CentOS in the direction we want it to go, while recognizing the limitations of any volunteer-run product that depends on the good graces of a public corporation for its raw material; or we can take our ball and go home in a huff to rage against the machine while running Slackware or whatever.

So for the love of all that is holy, and particularly out of respect for the time it takes to hit delete on all of the shitty replies to this terrible thread, please let's can the bullshit conspiracy theories and personal attacks and screaming and crying and throwing our rattle across the room.

Note, if you must, that I do not have a redhat.com email address, nor have I ever. I'm just a dude who deleted a lot of profanity from this email before sending it, I promise. I've spoken my piece, and do not intend to dignify this horrible thread with any further replies (or readings), so now's your chance to call me all sorts of horrible names without the risk that I might see it.

On Sun, Jun 22, 2014 at 3:20 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:

On 06/22/2014 05:53 PM, Johnny Hughes wrote:

...

On 06/21/2014 01:31 PM, Ljubomir Ljubojevic wrote:

...

On 06/21/2014 06:56 PM, Johnny Hughes wrote:

...

...

Just to emphasize, people want COMPATIBILITY with RHEL, that is why we use it. If there will be no PERCEIVED compatibility, people will start waling away from CentOS. As simple as that.

And the CentOS goal is full functional compatibility.

We do now have and will continue to have that.

Changing a number in the name does not impact that at all ... it just means we are trying to better describe what CentOS is.

That IS the point over board and users are arguing about. Just like "Beauty is in the eye of the beholder", so is the "truth" what something is or isn't. All of users are trying to PRESERVE what was established. We do not think CentOS should be redefined just because of minority that uses apps that are meant for certain point-in-time.

So if you choose to keep with this PR nightmare, be ready to have diminishing membership, instead of increasing it. That is at least what vast majority of us, majority of community, on this list think. If you were to conduct referendum on this issue, I think 99% of CentOS users would vote against.

And then, to the all that follow this, it would look like selected few, now on the payroll of company that has vested interest in future of CentOS distro/project will go against will of vast majority of projects community, and play in the hand of that same company and it's profits.

While we are at it, why is Red Hat owner of "centos.org" domain name? And why is the Red Hat owner of CentOS trademark? "The CentOS Project is a community project. The CentOS Project leadership has transferred the CentOS trademark to Red Hat for protection and stewardship. The CentOS Governing Board will be responsible for policing use of the mark."

Who voted on it? Larger Community hasn't.

In fact, up to this point I thought CentOS is just joining forces with Red Hat. But text of the announcement says "The new initiative is going to be overseen by the new CentOS Governing Board." So this is actually NEW project that will claim CentOS name, but will not continue as CentOS, but in fat will be OpenRHEL. Only when I put together 2 and 2, Boards intention to remove OpenRHEL from CentOS that existed until January did I understood that my arbitrary story about what might happen is actually right.

Whois on centos.org:

Registrant Contact Information: Name: Red Hat, Inc. Organization: Red Hat, Inc. Address 1: 100 East Davie Street City: Raleigh State: NC Zip: 27601 Country: US Phone: +1.9197543700 Fax: +1.9197543704 Email: Email Masking Image@redhat.com

Administrative Contact Information: Name: Domain Admin Organization: Red Hat, Inc. Address 1: 1801 Varsity Drive City: Raleigh State: NC Zip: 27606 Country: US Phone: +1.9197543700 Fax: +1.9197543704 Email: Email Masking Image@redhat.com

Technical Contact Information: Name: Domain Admin Organization: Red Hat, Inc. Address 1: 100 East Davie Street City: Raleigh State: NC Zip: 27601 Country: US Phone: +1.9197543700 Fax: +1.9197543704 Email: Email Masking Image@redhat.com

In light of this new revelation, if you go on with the change, count me out of any further contributing. I will continue to use it, but will welcome any attempt to restore old CentOS even under some other name.

What revelation ... Red Hat is now paying for the domain registration. We (the Project) don't have any money, we never have. Stuff costs money. We either get someone to sponsor our domain registrations, servers we build on, servers we mirror on ... or we pay for it out of our own pockets. That is the way it has been since the beginning. Not only have I spent the time I mentioned before in this thread, I have personally spent several thousand dollars of my own money over the last 10 years to purchase hardware or go to conferences to promote CentOS, etc. Karanbir has spent even more time and money than I have. All this stuff you get for free has cost me dearly over the years in both time and money. At one point it almost coast me my marriage.

We have opened up the entire process for the 7 distro to the community. We have the git repo completely open for public consumption at git.centos.org.

Every build log, built RPM, built SRPM (for those who would rather use those) is available here:

http://buildlogs.centos.org/

You can look at the packages in our build root for every build, see the result of every test that the RPM did while it built, etc. We have never been more open or forthcoming.

Not only that, but every mock config used is published here for the

build:

...

https://git.centos.org/summary/sig-core!bld-seven.git

Every script we are using to do things with the git tree is here:

https://git.centos.org/summary/centos-git-common.git

We could not possibly be more open ... you have never been able to see so much about the distro before or how compatible it is or is not.

There is nothing to hide here, absolutely everything is out in the open. No one else in the EL space is even close to this level of openness. That doesn't even include the discussions on the lists.

Then we did all the QA completely open, the branding search was completely open.

The process we use to build has not changed ... but now you can absolutely see every part of it.

How we build docker images ... open, right here:

https://git.centos.org/summary/sig-cloud-instance!build-instance.git

How do we do our comps.xml or live media, open and right here:

https://git.centos.org/project/sig-core

We are being completely open with everything and as such we think we should also be completely open about things like binary compatibility and the name. Giving something the exact same name implies certain things, not all of which are true. Saying something is binary (or bit for bit) compatible also implies certain things.

All we are trying to do here is be completely honest and complete open about the distro as a whole and the process to get it as a whole. So now everything is open, you can see everything about it all, and a number after the decimal point in the name and/or the difference in the word Binary and Functional is enough to make you mistrust something that you have been using for free for ten years?

There are too many thing going on simultaneously. This text bellow I wrote on-the-go, developing the story as I wrote.

1. I have a problem where I am not sure where I stand on who owns this

project. Is it of the entire community, or just of the people on the board? I was definitely out of these talks, and since I was not consulted (just like other 99,9% of users) that means CentOS Project was not mine, I do not own even the tiny peace of it. Since several of you guys poured your hart and soul into this project it kinda is OK, but that fact robes me of my own "ownership", even 0.00000001% of it. I was just helping out you guys from Board/core devs.

As I said, it is OK, you earned it, but that entails other things.

Inner circle, the board, true owners of the project decided to abandon the project and start a new one, CentOS 2.0, totally not consulting anyone from the rest of Community. There was no vote, no one even warned us something like this is possible.

All that happened is that you decided, worked on it for few? months and then announced that old cloning project is over, and that you will be using CentOS project trademark for a CentOS 2.0, while abandoning CentOS 1.0.

In CentOS 2.0 Red Hat has a lot of influence. They are your employers, they own the trademark (if they didn't they would just donated money for you to register domains under your CentOS), they are giving most of the hardware, there are moving THEIR source base directly to git.centos.org.

Red Hat is going to work developing their basically for-profit projects via their subsidiary CentOS Project. Part of that process is that they want to create a greater mental distance between RHEL and CentOS, so people stop identifying those two as same thing, paid-for and unpaid-for versions. I know CentOS was kind of necessary evil, bringing them new customers and producing expert admins, enlarging user base, but at the same time you were cutting in their profit. When economy was good, it was fine balance. But in few last years Oracle and SL cut in, subscriptions started to drop and investors started to ask for more profits.

Since trick with making 6.0 build complicated hurt both CentOS and turned out to be PR nightmare for friendly neighborhood Red Hat, they needed better approach. They need open source behind RHEL, but they need more mental distance so that using free-distro is available, but also further away from CentOS = free RHEL. So they gave you everything you needed/wanted, improving CentOS Project in the process, but there "few legal problems that need ironing out". I do not know how that idea was introduced, changing minor number to date of release, but I do know that effect is JUST what Red Hat needs for increased profits in the future. Not in new 1-2 years maybe, but when perception of CentOS != RHEL takes hold, more managers will choose to buy RHEL instead of keeping CentOS servers.

We users of old CentOS 1.0 liked our independence from Red Hat, were more the Fedora, we were independent. At least until problems with 6.0 were solved by secret help from Red Hat. Maybe this idea is preposterous, but at the time 6.0 building was problematic, at least few of users suspected Red Hat gave away some of the secrets to help stalled CentOS to reach "100% binary compatibility" goal. In hind perspective, this also looks like plausible scenario. It is all in mailing list archive of that period, questions how you guys managed to solve some of the problems, and you refused to give out secret sauce. No one was offended, we all were happy things picked up. But this troublesome build might indicated also problems with future builds, so that also might affected your decision to accept Red Hat's offer. Red Hat would get control over the build process, it would be recognized as leader, but would also solve them the their biggest process, having almost 100% clone for free.

Now there is CentOS 2.0, brand new, drawing on old brand name, and you are waiting for storm to blow over to implement point-in-time date as planed. Since all of the board members of CentOS 2.0 are in agreement to proceed as planed, only thing that MIGHT avert you is loud revolt of the users. And since this was brought only on CentOS-devel mailing list, there will not be much more people revolting. We will just woke up in brand new world where another Company won over Community, the 99%.

So I will try to prevent this voicing my concerns. I do not think I will achieve anything, but at least I will know I did my best.

-- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On 06/23/2014 08:55 AM, Lamar Owen wrote:

On 06/22/2014 03:20 PM, Ljubomir Ljubojevic wrote:

...

....

Much stuff snipped. My reply is to one basic point:

...

We users of old CentOS 1.0 liked our independence from Red Hat, were more the Fedora, we were independent. ...

Any 'independence' of Red Hat was at best an illusion. Who did all the work to get updates, security and other types, into the various source packages in the first place? Who set up the infrastructure and went a step beyond what GPL requires to release source to the public? Who paid the developers to make the fixes that the source code has?

With all due respect to the CentOS team, rebuilding is a far easier job than developing the distribution in the first place. This is not a slam against the CentOS team, by any means, but a recognition of just how much of Red Hat's work is and has always been in CentOS. There never was any independence from Red Hat in reality, since we have always been totally dependent upon Red Hat for the source.

If Red Hat had ceased to exist, all of the RHEL rebuilds would probably either cease to exist or would have been drastically crippled, as it takes a lot of developers to keep up with all of the various fixes that are being made.

All of this post is absolutely true .. the part I separated I wanted to specifically highlight. Without Red Hat releasing all the pieces, none of this is possible and with them releasing the pieces and with CentOS doing the builds completely in the open, it is simple to see exactly what is there and what it is built against, etc. So, the Core CentOS Linux distro is now what it has always been, a rebuild of RHEL sources that are now completely auditable. If we are not building something, its easy enough to see. If we are building everything we used to build, then regardless of the name/version then it is the same. That is the bottom line. Now you can see not only what we build, but exactly how it is built, in what order, against what libraries, etc.

On 21/06/14 17:56, Johnny Hughes wrote:

On 06/21/2014 08:49 AM, Ljubomir Ljubojevic wrote:

...

...

Just to emphasize, people want COMPATIBILITY with RHEL, that is why we use it. If there will be no PERCEIVED compatibility, people will start waling away from CentOS. As simple as that.

And the CentOS goal is full functional compatibility.

Johnny, I'm sorry to keep on at you, but this phrasing is another thing that bothers me.

For the last however many years (~10 years?) the CentOS Project has always stated the goal is "100% binary compatibility". Now the change to "full functional compatibility". It's not the same thing. Again, to me all these things just send a signal of trying to dilute the direct relationship that exists between CentOS and RHEL.

Some may see this as nitpicking, but I'm concerned that the primary stated goal for the last however many years has completely disappeared from all official CentOS sites. Searching the Wiki now only finds references to the phrase "100% binary compatibility" in archived release notes and the main website makes absolutely no mention of RHEL nor the relationship between the two distributions.

Why would the CentOS Project stop using the phrase "100% binary compatibility"? Have folks at Red Hat asked you not to use that phrase any more? Do you still aim for "100% binary compatibility"? If not, that's fine but lets get that fact out there so we all know where we stand. If so, then lets say it as it's a really clear indication of what CentOS aims to be - a 100% binary compatible clone of RHEL. Lets get it on the front page of the website and the Wiki so folks know exactly what they are buying into.

We do now have and will continue to have that.

Changing a number in the name does not impact that at all ... it just means we are trying to better describe what CentOS is.

On Sat, Jun 21, 2014 at 04:48:22PM -0500, Johnny Hughes wrote: <huge snip>

So, we have never been binary (byte for byte) compatible ... instead we wanted to be and checked for the things in the tmverifyrpms script above.

We just want to make sure we say what we are trying to do ... and the same file lists, linking the same libraries, within 10% of the size is it. So thats what we want and that is "functionally" but not "byte for byte" compatible.

I always figured that what you MEANT by binary compatible, is "they work the same, don't break linkage with SOs, and when you run it you won't observe any difference" other than branding.

On Sat, Jun 21, 2014 at 06:21:35PM -0500, Jim Perrin wrote:

There's no malicious intent or devious nature behind the phrasing change. Just the result of having a legal team inform us that sometimes "words mean things". It doesn't change the message, just how we present it.

There may well be no malicious intent on either side but with all the noise and FUD surrounding the current el7 source issues in multiple venues and the fact that people are _still_ leery about the Red Hat / CentOS relationship and, sorry to say, but in some circles people are still not past the release fiasco that was C6, it all adds up to distrust. _Any_ change is likely to not be welcomed at this point without a lot of explanation on the part of you and the rest of the CentOS core team. I would suggest something on the web site or wiki explaining why this fundamental change in product description is necessary.

John

On Sat, Jun 21, 2014 at 4:48 PM, Johnny Hughes johnny@centos.org wrote:

What does 100% binary compatible mean to you?

It means you need to know exactly what it is compatible with...

So, we have never been binary (byte for byte) compatible ... instead we wanted to be and checked for the things in the tmverifyrpms script above.

Bug for bug compatible (ABI level) is the way I take it.

But, changing the release versioning in an arbitrary way doesn't give any new functionality in return for the confusion it will cause. What if... you could use a timestamp in the release number as a transaction ID for the update repository? Then you could identify not only the base minor level but also the latest update status. And maybe with some tweaking to yum it would be possible to make repeatable updates that would be able to duplicate an update to that state.

major.minor.date format looks like a compromise that have the best of both worlds

Agreed ..... I actually also liked the additional proposal earlier of

Major.minor.SIG.date

Where Major.Minor is the contents of redhat-release from which the CentOS version is built SIG is core, cloud, ... Date is the source code extraction date (I guess this is more relevant than the build date)

SIGs potentially have a more complex case where they've got a particular code drop from Core and have then applied a particular source code tree from the SIG. An example would be where the cloud SIG starts work on 7.0.core.20140710 tree to include the latest software defined network drivers and this is finally available on 20140725 after some work. The date to present, in my view, is the SIG date (i.e. 20140725) but it is not clear how to distinguish the core release from which it is derived.

Tim

From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Roger Pena Escobio Sent: 21 June 2014 15:35 To: centos-devel@centos.org Subject: Re: [CentOS-devel] CentOS 7 and release numbering

Once again If the goal is to point to the fact centos 6.4 is different than rhel6.4 after 6.5 is out, then make something right when the differentiation start and not before You can release a new centos release package for 6.4 or you can do something on the repo, that make it clear to client, that something changed and updates do not work anymore unless the SA does some concious local change to make it not complain again, will that break some auto update on those clientes? Yes, but that would be desired to make it clear that something is requiered from the local SA in order to keep the box secure

But, I still see a big plus by having a release like mayor.minor.date, it is more flexible without breaking the old way , both side wins because a client could see/notice that their 7.0.x is too old when it was getting refreshed every now and then (asuming there will be respins more oftens that rh releases)

Ok, let me go further in a mental exercise, let say we make the change proposed and the .minor number is changed to .date of release. Lets imaging a year from that release there is serious vulnerability that put the world to check "am I vulnerable?". Manager or lazy SA check that we are running 7.20140701, they are not familiar with, they might even remember that was created when rhel7.0 was released but to be sure they go to a wiki and confirm that indeed that release of centos is the rebuild of rhel7.0 but they probably also notice that there are newer resping of centos based on newer releases of rhel, and probably they might notice that what they are running is no supported anymore raising more questions to them. What this might have different if we keep things as they are right now ? Probably because of what you are saying , that hypotetical person might hope/expect/ that centos is also following what redhat is doing and a fix will come in there way but at that point updates will not work unless conciously a manual change was performed and a the only update available might be a new centos release saying it is not supported

Make sense ? Again, having major.minor.date format looks like a compromise that have the best of both worlds

Thank roger

Sent from Yahoo! Mail on Android

________________________________ From: Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org>; To: <centos-devel@centos.orgmailto:centos-devel@centos.org>; Subject: Re: [CentOS-devel] CentOS 7 and release numbering Sent: Sat, Jun 21, 2014 10:42:26 AM

On 06/21/2014 05:00 AM, Ron Yorston wrote:

Johnny Hughes wrote:

...

What better way to communicate that they are not standalone but are all only part of the MAJOR release and a POINT IN TIME part of that major release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?

The current scheme represents <POINT IN TIME> as an integer that starts from zero and increments with each minor release.

I remain unconvinced that a YYMM representation of <POINT IN TIME> is any better.

It is not really better at conveying time, no. It is the same at conveying the time.

Where it is better is in denoting that Red Hat is doing things inside the 6.4 tree (again, just following the above example) while CentOS does not do those things inside our 6.4 tree after we release 6.5. We can't do them, even if we want to as we don't have the sources.

That is my whole point .. we need a way to convey a similarity and one point, while not being similar always. Having the exact same name does not convey that.

How do you suggest we do that and not ignore that there are potential differences after we move to the next point release? Do we just ignore that part?

Everything on this list that is newer than 2013-11-20 is in the RHEL 6.4 tree ... we don't and can't release any of it for our 6.4:

https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html

So our 6.4 tree is now significantly divergent from the Red Hat 6.4 tree, and our 6.4 tree is in the vault and not live anymore ... don't we have an obligation to our users to make sure they understand that there are differences?

UserA has some software that only works with 6.4 .. he sees CentOS-6.4 in the vault and grabs that to use with his software. He can't upgrade to 6.5 because it will break his software. Staying on our 6.4 tree will leave UserA vulnerable with security issues. If he is instead on the Red Hat 6.4 tree, he is still going to be able to get updates. Do we not have any obligation to change our numbering so that UserA can more easily tell this hugely major difference?

We don't really have the upstream point releases, we have different point releases. We release the main line CentOS-5, CentOS-6, and CentOS-7 ... we do point in time respins of ISOs and install trees, Red Hat does all this and a bunch more things also inside point releases. These two things are not EXACTLY the same ever, but they are very similar for one 6 to 8 month "period of time" (while they are OUR active release and Red Hat's active release) and they become increasing divergent after that point in time. That is what I am trying to convey here. Some people will argue that people have to pay for that other REd Hat 6.4 tree ... sure they do. They also have to pay the initial Red Hat 6.4 tree, they have to pay for everything there, thats how it works.

Everyone here thinks that we should just leave the point releases as is, knowing that now Red Hat is doing completely different things inside point releases and that we don't have an obligation to point out the differences?

On Jun 21, 2014 1:42 PM, "Johnny Hughes" johnny@centos.org wrote:

On 06/21/2014 05:00 AM, Ron Yorston wrote:

...

Johnny Hughes wrote:

...

What better way to communicate that they are not standalone but are all only part of the MAJOR release and a POINT IN TIME part of that major release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?

The current scheme represents <POINT IN TIME> as an integer that starts from zero and increments with each minor release.

I remain unconvinced that a YYMM representation of <POINT IN TIME> is any better.

It is not really better at conveying time, no. It is the same at conveying the time.

Where it is better is in denoting that Red Hat is doing things inside the 6.4 tree (again, just following the above example) while CentOS does not do those things inside our 6.4 tree after we release 6.5. We can't do them, even if we want to as we don't have the sources.

Why we don't have the sources? Isn't Red Hat obliged to give the sources with the binary packages?

That is my whole point .. we need a way to convey a similarity and one point, while not being similar always. Having the exact same name does not convey that.

How do you suggest we do that and not ignore that there are potential differences after we move to the next point release? Do we just ignore that part?

Everything on this list that is newer than 2013-11-20 is in the RHEL 6.4 tree ... we don't and can't release any of it for our 6.4:

https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html

So our 6.4 tree is now significantly divergent from the Red Hat 6.4 tree, and our 6.4 tree is in the vault and not live anymore ... don't we have an obligation to our users to make sure they understand that there are differences?

UserA has some software that only works with 6.4 .. he sees CentOS-6.4 in the vault and grabs that to use with his software. He can't upgrade to 6.5 because it will break his software. Staying on our 6.4 tree will leave UserA vulnerable with security issues. If he is instead on the Red Hat 6.4 tree, he is still going to be able to get updates. Do we not have any obligation to change our numbering so that UserA can more easily tell this hugely major difference?

We don't really have the upstream point releases, we have different point releases. We release the main line CentOS-5, CentOS-6, and CentOS-7 ... we do point in time respins of ISOs and install trees, Red Hat does all this and a bunch more things also inside point releases. These two things are not EXACTLY the same ever, but they are very similar for one 6 to 8 month "period of time" (while they are OUR active release and Red Hat's active release) and they become increasing divergent after that point in time. That is what I am trying to convey here. Some people will argue that people have to pay for that other REd Hat 6.4 tree ... sure they do. They also have to pay the initial Red Hat 6.4 tree, they have to pay for everything there, thats how it works.

Everyone here thinks that we should just leave the point releases as is, knowing that now Red Hat is doing completely different things inside point releases and that we don't have an obligation to point out the differences?

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On 06/22/2014 03:40 AM, Mustafa Muhammad wrote:

On Jun 21, 2014 1:42 PM, "Johnny Hughes" <johnny@centos.org mailto:johnny@centos.org> wrote:

...

On 06/21/2014 05:00 AM, Ron Yorston wrote:

...

Johnny Hughes wrote:

...

What better way to communicate that they are not standalone but

are all

...

...

...

only part of the MAJOR release and a POINT IN TIME part of that major release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?

The current scheme represents <POINT IN TIME> as an integer that

starts

...

...

from zero and increments with each minor release.

I remain unconvinced that a YYMM representation of <POINT IN TIME> is any better.

It is not really better at conveying time, no. It is the same at conveying the time.

Where it is better is in denoting that Red Hat is doing things inside the 6.4 tree (again, just following the above example) while CentOS does not do those things inside our 6.4 tree after we release 6.5. We can't do them, even if we want to as we don't have the sources.

Why we don't have the sources? Isn't Red Hat obliged to give the sources with the binary packages?

The Sources are available on git.centos.org.

On Mon, Jun 23, 2014 at 9:07 AM, Lamar Owen lowen@pari.edu wrote:

...

...

Why we don't have the sources? Isn't Red Hat obliged to give the sources with the binary packages?

Red Hat is obliged to give those sources to the same people to whom it give binary packages. Red Hat is not obligated to release those 'inside the old point release' sources to the public. Red Hat releases the mainline sources to the public. Of course, some of this may change for 7. So for EUS, Red Hat gives the sources to those people who they give binaries, that is, subscribers to EUS. That is the limit of what GPL requires.

The GPL requires that anyone who receives sources has the right to redistribute them freely, although Red Hat seems to think they can restrict this right if they do it by tying the restriction to the support contract.

On 06/23/2014 10:38 AM, Les Mikesell wrote:

The GPL requires that anyone who receives sources has the right to redistribute them freely, although Red Hat seems to think they can restrict this right if they do it by tying the restriction to the support contract.

It is a matter of opinion as to whether Red Hat's exercise of their right to terminate a subscription constitutes a 'restriction' on the right to redistribute source.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, 23 Jun 2014, Les Mikesell wrote:

The GPL requires that anyone who receives sources has the right to redistribute them freely, although Red Hat seems to think they can restrict this right if they do it by tying the restriction to the support contract.

I am aware of no such formal statement to specific that effect by Red Hat -- URL please?

About all I know are that there have been lots of speculation and inference by non-lawyers, which rarely ends well or with a result a lawyer might consider 'accurate' [1]

Trademark law is equally full of traps for geeks (and others) thinking that 'the law' is a well-formed logic engine, or state machine. At Michigan Law, I met and had a course with professor [Layman Allen] with 'game': 'WFF and Proof' [2] ... as noted a trainer in formal symbolic logic. Now Emeritus, it seems [3]

I find that 'the law' is not like that at all. It is more like a twisty cow-path, stomped out through lots of individual cases, which make up its life history [4] [5]. There was an interstical stained glass window with that quote at U Mich's Law School, but I cannot lay hands on an on-line photo of it

If you want legal advice, go buy legal advice. If you want Red Hat's view of binaries and Source matter, go buy access to it. You may wish to have your lawyer review the EULA first

M Go Blue

- -- Russ herrold

- ---------------start disclaimer-------------------

I_A_AL, but not your lawyer. I offer legal advice and formal opinion only within the confines of a previously established and explicit attorney-client relationship where privilege may be had; and NEVER on a public list server.

- ----------------end disclaimers ------------------

[1] http://orcorc.blogspot.com/2009/03/promoting-ignorance.html [2] https://www.oercommons.org/authoring/1364-basic-wff-n-proof-a-teaching-guide... [3] http://www.law.umich.edu/FacultyBio/Pages/FacultyBio.aspx?FacID=laymanal [4] http://www.michiganstainedglass.org/month/month.php?month=12&year=2007 [5] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1753389

Abstract: Lawyers from Justice Holmes’s day until today rally around the banner of his most famous quote, “The life of the law has not been logic: it has been experience.” Supposedly, this phrase reminds judges and other lawmakers never to let the law lose touch with the needs of ordinary people. In historical context, however, “the life of the law” says nothing about how judges should decide cases. Rather, it expresses Holmes’s view about how common law judges actually decide cases. More specifically, Holmes’s “experience” refers to judges’ mostly subconscious intuition, while “logic” refers to a vain attempt to systematize intuitively developed law. Proper understanding of Holmes’s famous quote, revealed through this Article’s historical analysis, helps to avoid an unfortunately common analytical distortion, and one which tends to stultify the law - - what Holmes called “the danger of inventing reasons offhand for whatever we find established in the law.”

Pull quote to pay attention to is: “logic” refers to a vain attempt to systematize intuitively developed law

On Mon, Jun 23, 2014 at 1:56 PM, R P Herrold herrold@owlriver.com wrote:

...

The GPL requires that anyone who receives sources has the right to redistribute them freely, although Red Hat seems to think they can restrict this right if they do it by tying the restriction to the support contract.

I am aware of no such formal statement to specific that effect by Red Hat -- URL please?

If they don't, then can someone who has support and access to the official RH versions work out a way to verify that the versions released publicly are always complete and up to date? And fix it if they aren't?

On 06/20/2014 02:25 PM, Trevor Hemsley wrote:

On 20/06/14 12:15, Johnny Hughes wrote:

...

You think it is much easier to explain a data breach costing your client in the field millions dollars because someone THOUGHT they had 7.1 EUS and all its security updates, just like RHEL has, when the tree is at 7.3? We need to prevent people from thinking is OK to stay on an old tree, it absolutely is not.

The people who don't stay up to date are the ones who have never heard of EUS and wouldn't know what it was if it bit them. They don't stay up to date because they don't even know they should and adding an incomprehensible date format to the release number won't make them do so either. The addition of the motd telling you how many updates are pending would do far more to address this than a random change to something that doesn't need changing.

It just adds confusion to the mix.

T

+1 on both aspects. telling how many updates are pending would be more useful by far than changing the naming scheme.

On 06/20/2014 12:06 PM, Tim Bell wrote:

The communication problems you raise are exactly the ones that we will have with our user community. Given the difficulties you have explaining it to those on centos-devel, imagine how we'll be explaining it to our thousands of users, external support lines and management chains.

I could explain a 7.0 or even 7.0.1406 but a 7.1406 with an associated wiki page would cause us real problems in the field.

i think that wiki page thing was mostly a non-starter, lets drop that for now. the ReleaseNotes are in the wiki, and I believe thats what it implied, the Release announcement + notes etc would clearly highlight what point release of RHEL we built from.

However, also consider that we might be able to do something on the machine itself, eg: lsb_release reports 7.0 and/or we can overload /etc/redhat-release to map to the RHEL version while /etc/centos-release can export both eg: CentOS release 7.1406 ( EL 7.0 )

( i dont think RHEL branding police will let us put RHEL in there, but we can certainly ask )

btw, the grounding of this issue is with me struggling to communicate why there are AMI's that say CentOS-6 that dont map 1:1 with CentOS-6.5 installer tree, although 6.5 is the last released CentOS version.

On 06/20/2014 11:53 AM, Greg Lindahl wrote:

The user problem is that either users are at the tip, or not. Having different version names might make that more obvious, but I bet that people who don't stay at the tip won't notice.

Thats a great way to put it - and i think it highlights the issue as well, the idea of the 'tip' should always be '7' and never 7.0 or 7.1, since that what everything uses ( yum, installer, metadata etc ). And realistically, I think everyone sort of works with that. Switching from 7 to 7.x is a manual step anyway, and I assume that people doing that would carry on doing it regardless.

The issue becomes complicated when there are point-in-time snapshots, even from the CoreSIG for things like docker images, cloud images etc where we need to have new ones done ( hello heartbleed! ) which dont have a connection with an upstream 1:1 - these images do still need to retain an upstream connection to the last point release, and having the 7.YYMM notion helps with that.

Remember that the machine instance is still going to report ( or it should report 7.0 via lsb_release etc ).

Does it make things easier if we also adopt a Name for the release ? eg. 7.1406 (Alpine) to indicate 7.0 ? and all Alpine releases would be 7.0 dereived.. with Balsa being 7.1 etc ? I'm not a big fan of naming, becuase then its no longer a case of running CentOS-7/Final for the large chunk of the userbase who do track tip, it will be CentOS-7/Some-name. Ideally, we would leave the Name tag for SIG's to pickup. eg. CentOS Linux 7.1406 Final is the distro and CentOS-7.1406 Gluster migth be a variant installer from the Storage SIG folks.

So in summary : I think we should continue to use CentOS-7/Final as the main distro that everyone runs, and use the 7.YYMM to indicate the isos set, with metadata inside the installed machine still reporting whatever rhel point release it originated or maps to. Everything that has happened in the past, stays intact - except the ISOS release is announced as '7 1406 - rebuilt from RHEL 7.0 sources'.

- KB

Karanbir Singh wrote:

So, personally - I think the community feedback was great, how badly we communcated the idea was apareny and clear for everyone to see. And I personally feel that a large chunk of the response was down to fear of change in areas that we had never even imaged were going to change.

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

Regardless of how well the topic was communicated, my reading of this thread was that most respondents were against the idea

I for one would still like to keep the version numbering in line with RHEL

Thanks

James Pearson

On 06/20/2014 12:15 PM, Trevor Hemsley wrote:

On 20/06/14 11:35, Karanbir Singh wrote:

...

Hi,

On 06/18/2014 06:02 PM, Akemi Yagi wrote:

...

...

With the release of CentOS 7 just around the corner, have the board members made a decision?

No we havent, its something we've been iterating over but there is no decision made at this point.

The only place I've seen where this makes sense is for things like the docker/AMI/etc images where a new set might be produced to include a security update in mid-point release. For the rest, it doesn't make any sense to me to change.

but as Greg pointed out - isnt everyone else only using the major version? CentOS-6 and CentOS-7 ? that stays as it has always been.

On 06/20/2014 12:20 PM, Manuel Wolfshant wrote:

My point exactly. The SIGs (who will introduce new stuff anyway ) can derive the name as they please . The core should stay as it was.

Alternative media for the distro - like cloud images etc are all coming from and a part of the Core distro, its not SIG specific.

- KB

On 06/20/2014 12:27 PM, Manuel Wolfshant wrote:

On 06/20/2014 02:22 PM, Karanbir Singh wrote:

...

On 06/20/2014 12:20 PM, Manuel Wolfshant wrote:

...

My point exactly. The SIGs (who will introduce new stuff anyway ) can derive the name as they please . The core should stay as it was.

Alternative media for the distro - like cloud images etc are all coming from and a part of the Core distro, its not SIG specific.

even though, one can label the isos and the image as one please. for instance freepbx ships "Stable-5.211.65-14 " which is based on centos 6.5 ( hence the 65 in the name ) , freepbx 2.11 ( hence 211 in the name ) and so on

sure, the SIG's can number and release in a way that makes the most sense for them, but in this case were talking about the Core Distro itself. Which isnt influenced by the SIGs

On 20/06/14 11:35, Karanbir Singh wrote:

Hi,

On 06/18/2014 06:02 PM, Akemi Yagi wrote:

...

With the release of CentOS 7 just around the corner, have the board members made a decision?

No we havent, its something we've been iterating over but there is no decision made at this point.

...

We have seen an overwhelming number of responses from the community members. Many of them are long time contributors who do not mind "having late-night coffee-fueled work sessions after the family's gone to bed".

Now the world is watching (between the FIFA games) how the board would handle the situation in which their idea/plan does not get support from the community.

So, personally - I think the community feedback was great, how badly we communcated the idea was apareny and clear for everyone to see. And I personally feel that a large chunk of the response was down to fear of change in areas that we had never even imaged were going to change.

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

No, not really. I've yet to see any technical issue described that this proposed change would fix, that couldn't be fixed just as easily outside of the release numbering name space.

So what it really boils down to is communication, and not technical reasons as to why there is resistance to this change. And if we are able to find a clear / clean way to communicate the relationship - something that the community at large agree's to, then we have a plan going forward.

Well yes, it is a communication issue really. The board expressed a desire to change the release numbering system and the community categorically rejected that proposal. The communication issue seems to be that the board still aren't listening to the community but continue trying to persuade the community that this is a good idea.

I seem to be saying this a lot, but getting better at what we do should never really be optional - and I definitely feel that the numbering change allows us to do just that. We just need to find a way to to communicate and overcome the emotional resitance to change. CentOS Linux is going to always retain RHEL mapping for 1:1 rebuild, as a best effort

• and now more open and more visible than before. Now, reparse the

thread with that statement in mind and you will find that the biggest resistance goes away completely.

Ford make cars, not push bikes. Ford decide it would be a good idea to make slimmer thinner cars for narrower streets despite the fact that their core market has nice wide roads. Then ford decide to make a 3 wheeled car, as the forth wheel really is unnecessary and thus just wasteful. In the interests of environmental improvements Ford decide it would be good to do away with the engine, as it's only a source of pollution and not environmentally friendly. Finally Ford decide that losing the third wheel will make the vehicle lighter and easier to peddle. Ford now make bicycles. I now drive a German car because all I really wanted was a car, not a bicycle.

Trust is something you have to earn, over time. Once the community has seen, over time, that there is no intention of changing the Core disto then you will have earned that trust. Coming out of the gates in the first few months with proposals to change such fundamentally important aspects of a distro's identity as the release numbering scheme, especially when it so directly corresponds to the upstream numbering does nothing to establish / earn trust. Stating nothing is going to change whilst changing fundamentally important things the community has strongly rejected breaks what little trust you have.

So I guess at this point the community, having expressed it's opinion, is waiting to see what decision the board makes and will judge accordingly.

On 06/20/2014 01:49 PM, Trevor Hemsley wrote:

On 20/06/14 13:34, Ned Slider wrote:

...

Well yes, it is a communication issue really. The board expressed a desire to change the release numbering system and the community categorically rejected that proposal.

Other than members of the board, I have yet to see a single response from any community member who thinks this is a good idea. That either means you (the board) are still not explaining what the perceived problem is that you are trying to fix or that your idea has failed to gain any traction at all and that you're going to go ahead and do it anyway because you can.

I know which of those two alternatives I think is happening.

I realise the issue here really is that we should not have started the conversation without putting something tangiable out there, so people could see the extent of and the implications of what is being proposed.

At the moment, most of what is coming through is just fear based on exaggerated assumptions.

I prolly sound frustrated, certainly am. But then I guess the vocal few are never really a true representation of community.

Anyway, there are some interesting options on how we can and might also be able to do creative around around the edges, lets explore those as well. the aim, after all, regardless of what some people are harping on about, isnt to break the distro - its just to facilitate other optinal things.

- KB

On 06/20/2014 02:38 PM, Akemi Yagi wrote:

On Fri, Jun 20, 2014 at 6:04 AM, Karanbir Singh mail-lists@karan.org wrote:

...

I prolly sound frustrated, certainly am. But then I guess the vocal few are never really a true representation of community.

Most of us are frustrated. "vocal few"? Personally I'm very disappointed to hear this from you. If I were a board member, those "few" would be the most I care about. Those "few" would be the people I want to hear from. Those "few" would be the ones I depend on most. What is "a true representation of community" after all?

CentOS is used by quite a few people, in quite a few different demographics and use-cases around the world, a great representation of community would be if we have a voice from a lot more of those.

The other aspect is that when someone is making a site specific decision, you look at just your own setup - when considering something from the project perspective, it becomes important to look at the big / winder perspective as well

On 06/20/2014 07:34 AM, Ned Slider wrote:

On 20/06/14 11:35, Karanbir Singh wrote:

...

Hi,

On 06/18/2014 06:02 PM, Akemi Yagi wrote:

...

With the release of CentOS 7 just around the corner, have the board members made a decision?

No we havent, its something we've been iterating over but there is no decision made at this point.

...

We have seen an overwhelming number of responses from the community members. Many of them are long time contributors who do not mind "having late-night coffee-fueled work sessions after the family's gone to bed".

Now the world is watching (between the FIFA games) how the board would handle the situation in which their idea/plan does not get support from the community.

So, personally - I think the community feedback was great, how badly we communcated the idea was apareny and clear for everyone to see. And I personally feel that a large chunk of the response was down to fear of change in areas that we had never even imaged were going to change.

I'm also assuming that my last email to this thread cleared all the technical issues that people had brought up, if there are still some outstanding now is a great time for people to raise those.

No, not really. I've yet to see any technical issue described that this proposed change would fix, that couldn't be fixed just as easily outside of the release numbering name space.

...

So what it really boils down to is communication, and not technical reasons as to why there is resistance to this change. And if we are able to find a clear / clean way to communicate the relationship - something that the community at large agree's to, then we have a plan going forward.

Well yes, it is a communication issue really. The board expressed a desire to change the release numbering system and the community categorically rejected that proposal. The communication issue seems to be that the board still aren't listening to the community but continue trying to persuade the community that this is a good idea.

...

I seem to be saying this a lot, but getting better at what we do should never really be optional - and I definitely feel that the numbering change allows us to do just that. We just need to find a way to to communicate and overcome the emotional resitance to change. CentOS Linux is going to always retain RHEL mapping for 1:1 rebuild, as a best effort

• and now more open and more visible than before. Now, reparse the

thread with that statement in mind and you will find that the biggest resistance goes away completely.

Ford make cars, not push bikes. Ford decide it would be a good idea to make slimmer thinner cars for narrower streets despite the fact that their core market has nice wide roads. Then ford decide to make a 3 wheeled car, as the forth wheel really is unnecessary and thus just wasteful. In the interests of environmental improvements Ford decide it would be good to do away with the engine, as it's only a source of pollution and not environmentally friendly. Finally Ford decide that losing the third wheel will make the vehicle lighter and easier to peddle. Ford now make bicycles. I now drive a German car because all I really wanted was a car, not a bicycle.

Trust is something you have to earn, over time. Once the community has seen, over time, that there is no intention of changing the Core disto then you will have earned that trust. Coming out of the gates in the first few months with proposals to change such fundamentally important aspects of a distro's identity as the release numbering scheme, especially when it so directly corresponds to the upstream numbering does nothing to establish / earn trust. Stating nothing is going to change whilst changing fundamentally important things the community has strongly rejected breaks what little trust you have.

So I guess at this point the community, having expressed it's opinion, is waiting to see what decision the board makes and will judge accordingly.

So let me see if I have got this straight.

I have been working 100 hour weeks for 10 years to help create and maintain a Linux distribution which people can use for free. Many huge companies like Twitter and Facebook and GoDaddy used it to build multi-million dollar companies and it is the 3rd most used operating system on the Internet. The vast majority of that time was voluntary.

I finally get the opportunity to actually work on the project full time to make it better and somehow I am purposely recommending something that would somehow sabotage it? How does that make any sense at all?

Have we ever done anything with CentOS that was not in the best interest of the community? We may not have always had the resources that we wanted or been able to do things as fast as we would like, but we have always tried hard and done the best we could do.

And a secondary point ... YOU are telling me that I have somehow done something that "breaks what little trust you have" (the "you" meaning the CentOS project, I suspect).

If you have so little trust in ME at this point, I don't know what to think. I have dedicated a vast majority of my adult life on this project and there is absolutely nothing in the world but my family that means more to me than CentOS does and for you to suggest that I (or we) have some alterer motives to somehow sabotage CentOS is absolutely breathtaking.

On 06/20/2014 09:52 AM, Alessandro Ren wrote:

I dont think anyone lacks confidence in your work or in CentOS and everybody appreciate the time you've dedicated to the project. I my self have not yet clearly understood the real idea behind the new versioning system and I really dont know why the classic model would not work. I think the main success of the project is being closely related to RHE. My main concern is the risk of not keeping with the last security updates or not seeing them as clearly due to the new versioning.

I believe once we have been able to produce the two images for people to play with as Karanbir suggests that the above concern will be clearly and practically addressed. The goal is to not only to continue to deliver to existing users, but grow that base in addition to become relevant in new areas as we have started to show traction with CentOS in OpenStack. With the SIG and closer association of RDO and CentOS for example we have moved the User survey that Tim Bell runs 40 points from what I can work out from Ubuntu our way. That's huge. This has to be good for the project and the users and I believe we can do far more, how about 1st in a future survey? Goal is the grow the project, our scope of influence for the project, but NOT break things.

I'm pretty sure once we have been able to create an example image >90% of people will have 0 change in experience. Let's get next round of comments after we have been able to play with it

Let's take ground and not break stuff. Carl.

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.

Tim

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?

On 06/20/2014 02:52 PM, Nathanael D. Noblet wrote:

So this is the clearest explanation - not sure why it wasn't clearer to me earlier. I mean I got the basic idea, once RHEL moves on to a newer point release updates to their previous point releases costs money and is not available for CentOS to rebuild and maintain an identical tree.

So as a user that has never paid for RHEL I wasn't 100% aware that this existed. I've always basically kept my systems up to date just assuming that the point releases were kind of like Microsoft's Service Pack X. Having never paid for a fix to be ported to a previous Service Pack level its not till today that it makes sense that MS would allow clients to pay for that kind of service.

All this to say is that I never thought I could stay on a point release. Also I'm wondering if someone doesn't update the centos-release-6.5 rpm won't they still be getting updates anyway? I just checked it it looks like you are.

We handle this by pointing the yum repositories at the major version. So /6/ instead of /6.5/ for example. When 6.6 comes out, we'll alter the symlink to point /6/ to the 6.6 tree instead of the 6.5 tree.

The problem with this is that you'll either have users who NEVER update, or they update but never know what version they're on.

The users who don't update tend to fall into two camps:

1. It's working, DON'T TOUCH IT!

2. My vendor for $foo told me it's only supported on this one specific version so I'm staying there no matter what.

Here's my simplistic suggestion, don't maintain those older trees. One tree lastest version for the major version. This is the clearest signal that there is only ever one area where updates occur. Or if there is a good reason to keep older packages in their own point release, make the centos-release always point to the 'latest' repo. As in it doesn't matter if I have centos-release-6.2/6.3/6.4 they always point at /repo/latest?

That's mostly what we do, via the symlink method explained above.

On our mirrors, we only keep the latest tree. We do however archive legacy trees on the vault mirrors so that people who need to duplicate an environment from a given time period can do so. You'd be amazed how often people have to recreate the past.

Today, in CentOS 5 and 6, when I issue a yum update, lets say, on CentOS 5.5, it will bring me to the latest CentOS 5 version, 5.10 for example. This same behavior will work in CentOS 7? Or I have to change my repos settings? I didnt know about the RedHat versioning system either and I understand the need to adapt the CentOS versioning too. I think we all want to be able to tell our customer / users that they must update do CentOS 7.1 to fix some security issue instead of checking if they are on 7.20140619 and must update to 2.20150704. Although, it is possible to release and security patch for verion 7.0 without releasing a veriaon 7.1 and that would be done on a 7.xxxxxx branch?

[]s.

----- Original Message ----- From: "Nathanael D. Noblet" nathanael@gnat.ca To: centos-devel@centos.org Sent: Friday, June 20, 2014 4:52:09 PM Subject: Re: [CentOS-devel] CentOS 7 and release numbering

On Fri, 2014-06-20 at 10:38 -0500, Johnny Hughes wrote:either

On 06/20/2014 08:52 AM, Alessandro Ren wrote:

...

Johnny,

I dont think anyone lacks confidence in your work or in CentOS and everybody appreciate the time you've dedicated to the project. I my self have not yet clearly understood the real idea behind the new versioning system and I really dont know why the classic model would not work. I think the main success of the project is being closely related to RHE. My main concern is the risk of not keeping with the last security updates or not seeing them as clearly due to the new versioning.

[]s.

I said at the beginning of this topic, but I will say it again here as clearly as I can ...

Red Hat has a tree ... we can pick any one, I'll use 6.4 as an example.

When Red Hat releases 6.4 they release an ISO set and a tree. Red Hat splits their tree up into several versions, for which they can charge varying amounts of money (Server, Workstation, HPC Node, Client, etc). CentOS has no need for these designations and we flatten it out into one main repo .. since everything is free in CentOS. We have groups that mimic the functionality of those segments.either

So, at the time of release, other than the things we purposely do not build (install numbers for the ISOs, RHN subscription items) the version numbers match up almost exactly as we use the source from RHEL to make CentOS.

The differences between the Red Hat and CentOS trees start to happen AFTER the next release.

When 6.5 comes out, we again use the RHEL source code and do our thing ... and we take the 6.4 tree out of production and put it in our vault. This is because Red Hat does not publicly release changes for that tree anymore. However, behind the scenes, Red Hat does do changes to that tree for their paying customers. The release updates for that 6.4 tree for up to 3 years. This is something they have always done and something CentOS has never been able to do. Those things are going to continue in the future as well, Red Hat makes the source code publicly available for the "Current" tree and we will continue to consume it. They will not make available the code for the extended parts of the tree, just like before.

So, if one is using RHEL and wants to stay on the 6.4 tree, you can andeither you can still get updates. If one is using CentOS and wants to stay on our 6.4 tree, you get no updates.

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.

Now, we have had people say it is a strawmnan issue, even here on this list .. but if we can change the perception AND more accurately portray what a CentOS point release really is (a point in time release of the main tree) by changing the way we talk about the name ... while leaving the content of the distro exactly as it is, then why would we not want to do that. either The only thing I can think of is that some people actually WANT to misrepresent what the point release actually is. That some people actually want users to think that 6.4 CentOS and 6.4 RHEL are actually the same thing ... which they are not. They are similar for a period of time and then radically different later.

How is what I said inaccurate?

So this is the clearest explanation - not sure why it wasn't clearer to me earlier. I mean I got the basic idea, once RHEL moves on to a newer point release updates to their previous point releases costs money and is not available for CentOS to rebuild and maintain an identical tree.either

So as a user that has never paid for RHEL I wasn't 100% aware that this existed. I've always basically kept my systems up to date just assuming that the point releases were kind of like Microsoft's Service Pack X. Having never paid for a fix to be ported to a previous Service Pack level its not till today that it makes sense that MS would allow clients to pay for that kind of service.

All this to say is that I never thought I could stay on a point release. Also I'm wondering if someone doesn't update the centos-release-6.5 rpm won't they still be getting updates anyway? I just checked it it looks like you are.

Here's my simplistic suggestion, don't maintain those older trees. One tree lastest version for the major version. This is the clearest signal that there is only ever one area where updates occur. Or if there is a good reason to keep older packages in their own point release, make the centos-release always point to the 'latest' repo. As in it doesn't matter if I have centos-release-6.2/6.3/6.4 they always point at /repo/latest?

On 06/20/2014 10:16 PM, Les Mikesell wrote:

On Fri, Jun 20, 2014 at 2:52 PM, Nathanael D. Noblet nathanael@gnat.ca wrote:

...

So this is the clearest explanation - not sure why it wasn't clearer to me earlier. I mean I got the basic idea, once RHEL moves on to a newer point release updates to their previous point releases costs money and is not available for CentOS to rebuild and maintain an identical tree.

When a service exists that 'costs money', it implies that there are situations that require customers to pay for it. Which would be some application/configuration where doing the next point update will cause known breakage or at least requires some lengthy testing before proceeding.

...

Here's my simplistic suggestion, don't maintain those older trees.

They don't now. At the point releases, all of the old intermediate updates go to the vault so the mirror sites don't have to store them and updates only go all the way to current. But, if you had to reconstruct a back-rev system that had some, but not current updates (and given the situations where current updates cause breakages, there can be reasons to want to do that) it is very difficult. Say you wanted to re-create a 6.3 CentOS with updates up to just before 6.4 was released you'd probably have to look at the timestamp on every package in the vault and download/install each package in the relevant timeframe.

But, as far as I could understand, changing 7.0 to 7.20140620 (or what ever date) and changing NOTHING ELSE?, as it was suggested, it would not change a thing. It was clearly said that there will not be any intermittent releases in between 7.0 and 7.1 for example, so this change should only be a PR stunt, and all that comes to mind is that Red Hat would like to brake a bond between RHEL and CentOS and convert it into another staging area, "learn how to work with CentOS and then you can switch to RHEL", and to, in doing so, reduce the number of companies who will dare to use CentOS instead of RHEL.

I also can not get from impression that CentOS is becoming just a carcass, a shell for Red Hat projects. Source rpm's will not be published by Red Hat anymore, CentOS git will become a source of Open Source projects that will use similar but NOT the same rpms (binary compatibility?), something like SuSE and OpenSuSE, members of SL transferred to CentOS project, and SL guys are discussing if they will start just rebuilding CentOS packages (from git), so it all looks like Red Hat found a format to distance from releasing source rpms that can hurt their business by clever creation of uneasiness within users that use both RHEL and CentOS, braking in the process the unofficial support of major software distributors that SO FAR identified RHEL and CentOS as the same thing. And change of direct link between RHEL and CentOS would be a last nail to the coffin.

I AM really trying, but I can not understand what CentOS board wants to do other then this PR breakage.

I will, of course, hold off my final judgment allowing I could be wrong.

On 21/06/14 02:37, Johnny Hughes wrote:

On 06/20/2014 04:50 PM, Ljubomir Ljubojevic wrote:

<snip>

...

But, as far as I could understand, changing 7.0 to 7.20140620 (or what ever date) and changing NOTHING ELSE?, as it was suggested, it would not change a thing.

You are EXACTLY right ... it will not change anything about the distro at all .. EXCEPT be a better description of what CentOS is. A point in time rebuild of the major branch. It has the "major" and it has the "point in time". It perfectly describes exactly what CentOS is.

...

It was clearly said that there will not be any intermittent releases in between 7.0 and 7.1 for example, so this change should only be a PR stunt, and all that comes to mind is that Red Hat would like to brake a bond between RHEL and CentOS and convert it into another staging area, "learn how to work with CentOS and then you can switch to RHEL", and to, in doing so, reduce the number of companies who will dare to use CentOS instead of RHEL.

So here we have the essence of the issue, clearly described.

It may be "a better description of what CentOS is" but it's also is a step further removed from RHEL. It's making a change that isn't a direct consequence of legal or trademark issues.

So there is no technical issue to solve or overcome, in the core distro. It's a rebranding exercise to overcome a perception people may or may not have about point releases.

As many others have said, I believe such a change does more damage than good for all the reasons previously mentioned numerous times.

Johnny - it's not that anyone doesn't trust you (or KB), it's more that everyone knows once you start chipping away at the edges of the cornerstone of the project, it's no longer a cornerstone. And we all know from personal experience that it's easy to have principles as an individual, but sometimes it's not so easy when you are employed by an employer whose goals are in conflict with your own goals as you highlight below. Please don't take this as an affront to your own personal standards, it's not intended to be - I'm just trying to express what everyone is feeling.

If you are asking if Red Hat would rather have people buy RHEL for every server out there instead of using CentOS, sure they would. Do they want to convert CentOS installs to RHEL .. absolutely. This should not be a surprise. They also want to convert any other Linux out there to RHEL. And the CentOS team wants to convert all installs to CentOS. I bet the Ubuntu team wants to convert all Linux installs to Ubuntu as well .. at least I hope they do. It would be rather silly to shoot for 2nd or 3rd place.

On 06/21/2014 01:02 PM, Johnny Hughes wrote:

On 06/21/2014 05:32 AM, Ned Slider wrote:

...

On 21/06/14 02:37, Johnny Hughes wrote:

...

On 06/20/2014 04:50 PM, Ljubomir Ljubojevic wrote:

<snip>

...

But, as far as I could understand, changing 7.0 to 7.20140620 (or what ever date) and changing NOTHING ELSE?, as it was suggested, it would not change a thing.

You are EXACTLY right ... it will not change anything about the distro at all .. EXCEPT be a better description of what CentOS is. A point in time rebuild of the major branch. It has the "major" and it has the "point in time". It perfectly describes exactly what CentOS is.

...

It was clearly said that there will not be any intermittent releases in between 7.0 and 7.1 for example, so this change should only be a PR stunt, and all that comes to mind is that Red Hat would like to brake a bond between RHEL and CentOS and convert it into another staging area, "learn how to work with CentOS and then you can switch to RHEL", and to, in doing so, reduce the number of companies who will dare to use CentOS instead of RHEL.

So here we have the essence of the issue, clearly described.

It may be "a better description of what CentOS is" but it's also is a step further removed from RHEL. It's making a change that isn't a direct consequence of legal or trademark issues.

So there is no technical issue to solve or overcome, in the core distro. It's a rebranding exercise to overcome a perception people may or may not have about point releases.

As many others have said, I believe such a change does more damage than good for all the reasons previously mentioned numerous times.

But, CentOS started out with different numbering that Red Hat. They were doing 3 update 3 and not 3.3. They usually abbreviated it 3u3 and not 3.3. We were different because we did not necessarily want to convey we did everything, only that we were similar at that one point in time. Then Red Hat changed their numbering. So CentOS and Red Hat did not always have the same numbering.

CentOS still grew to become the most used Linux distribution in the world and Twitter, Facebook, GoDaddy, and any other number of companies still chose to use it for their needs. It is in use in colleges all over the world. In movie maker rendering farms. The number did not have to be the same for those things to happen. It does not have to be the same now either. If CentOS was identical, over the lifetime of the product, then I would want it to be numbered the same. But it is not the same, so why do we want the same number?

Now I see confusion in the name that I would like to resolve, and at the release of a completely new main branch seems the perfect time to do it. So everyone thinks that 7.1406 better describes what a CentOS release really is, but they don't want to do it. Interesting.

Johnny, I have more vivid imagination then most people. I can think of all different possible outcomes. That helps me to do what I do best, find best solutions to the problem at hand, even if people with the problem do not see it.

So that story telling I wrote had a purpose. That is most far fetched story I could muster, but it is also what many in Linux community will be thinking. It does not matter what you guys really think or do, but it matters what will PEOPLE think. And you can not control what they will think, no matter how hard you try.

When you guys were hired by Rad Hat, I saw it as a good thing for you and your dedication. BUT, that does not mean you could not be manipulated into some things. Setting someones mind in the desired direction is not that hard as people think. So this not my vote of non-confidence, just show of confusion you are producing in CentOS community. It is better your board to be confronted with this possible scenario now then after "s**t hits the fan".

First of all, ALL of the blogs refer to RHEL minor versions as 5.10, 6.5, 7.0, etc. It is easier to think in those terms, to "normalize the situation". All Linux distributions use this versioning schemes. Maybe you even were "godfathers" to that unofficial naming, but it stuck with public. I will say it again, RHEL! minor version are referred to as 6.5, not 6u5 by almost all non-Red Hat people in Linux Community. It's like carved in stone. There is no way anyone will start calling it 6u5.

Same goes to a link between CentOS and RHEL minor versions. CentOS 6.5 = RHEL 6.5 (with very small changes that can not be avoided). Also carved in stone. It will not change in 20 years, maybe never is everything stays the same. And everyone like it that way.

So changing versioning scheme will brake that bond between RHEL and CentOS as it's CLONE! Something people are COUNTING on. many do not have money for RHEL, but want it's stability and want to use apps that work on RHEL. So they are counting on that unbreakable bond, link, they like the idea of CentOS being 99% clone of RHEL.

As soon as you change versioning scheme, that bond in peoples minds would be broken, and almost-all would see it as just another RHEL lookalike, but not CLONE, just like SuSE and OpenSuSE. If before RHEL -> CentOS relation was close to MS-DOS Original -> Pirated MS-DOS, after change it would be more like MS-DOS -> PC-DOS, similar, claimed to do what ever exactly the same, BUT, in peoples minds there will be doubt wedged between RHEL and CentOS. Even I would FEEL so, no matter how my mind would try to convince me.

The main problem in perception is that you do not want to change anything else. THAT is part that is evoking emotional response into thinking there is something else behind it.

Example (dates are arbitrary): 7.0 -> 7.20140621 7.1 -> 7.20140910

When 7.20140910 comes out, system of updates will be the same. 7.20140621 branch will go into vault, rpms from updates repo will be merged to 7.20140910 and "yum update" will update system to 7.20140910 + latest updates. If some image needs to stay on 7.20140621, it will NOT be able to, update will move it along to next minor version. So nothing is gained.

If you were, prior to 7.20140910, to release 7.20140909, which would be 7.20140621 + all the updates to that point all in one repository (Fedora Everything?), then versioning change would have some purpose. But on the other hand, if you want to create base+updates snapshots in time, I would prefer if we would keep 7.0, 7.1 versioning for normal usage, and then create such snapshots 7.20140909 with accompanying repositories which would be filled with only security fixes?

Keep in mind that most of "old" users (using only single/unrelated server(s)/desktop(s)) want to keep everything the same, that is what we "signed on" by choosing CentOS.

Cloud images, SiG's, that is what interests only/mostly "new" users with much higher technical knowledge. High enough to know how to keep their systems the way they want them.

Any change to another direction then it was so far should be ADDITION to existing practice, not something to turn things upside down and chase away old users.

Johnny,

...

Red Hat has a tree ... we can pick any one, I'll use 6.4 as an example.

...

When Red Hat releases 6.4 they release an ISO set and a tree. Red Hat splits their tree up into several versions, for which they can charge varying amounts of money (Server, Workstation, HPC Node, Client, etc).

What about this as a reasonable compromise on the proposed version numbering?

<major>.<minor>.<date-code>

with the <date-code> in ISO8601 format (four-digit year, two-digit month, two-digit day).

This would translate as CentOS <major> version built from RHEL "baseline" <major>.<minor>, plus all publicly available updates as of <date-code>. ("baseline" = RHEL ISO set, for example: RHEL 6.4)

By using ISO-8601 format for the <date-code> ensures the least confusion when parsing it as a date field and it also sorts properly / compares properly when looking at previous dates.

Applying the above as the pattern, a RHEL 7.0 baseline + CentOS 7 updates as of 2014-06-20 would result in this as a version string:

7.0.20140620

Easy to parse for both the humans and the computers; relatively easy to understand for both old and new folk. Humans might understand better that updates for a particular branch (for example: 6.4) end after a given date. And management might understand better, why move from 6.4 to 6.5; because no patches/updates for 6.4 after YYYY-MM-DD.

Asking the humans, What is the patch date of your system? = read me the eight-digit number on the right-hand side of the version string. Is that number earlier (sometimes much earlier) than the current date? Yes = use 'yum update' to bring the system up to date; no, proceed to next step in troubleshooting issue, with a reasonable assurance that they are on a current release.

This helps focus on the two important parts, the <major> version and the <date-code>, while still keeping the <minor> field available for those who are comparing their CentOS install with relatively comparable system that was installed from a RHEL ISO media set.

Nothing would have to change regarding the current policy of CentOS not providing updates for a previous <minor> baseline once it moved forward to a new <minor> baseline. Installing from an older ISO image within the same <major> version of CentOS and then calling 'yum update' should still result in the system being brought up to date with the latest <minor>.<date-code> set of patches/updates.

For the various SIGs; if they had separate spins of the media, they could use a suffix attached to the core version string; for example: CentOS 7.0.20140620-cloud.<cloud-version>.

Thank you and your team for providing us with CentOS over the years.

Cheers!

Simba Engineering (long-time UNIX, Linux, and many other UNIX-based OSes since UNIX v7 :-)

On 06/09/2014 10:47 AM, Les Mikesell wrote:

On Mon, Jun 9, 2014 at 9:33 AM, Jim Perrin jperrin@centos.org wrote:

...

For lazy users who refuse to read or learn... I have very strong, and very negative opinions of those sorts of people. They leave disaster in their wake no matter what distro they run.

[...]

...

I want to see CentOS grow in usage and become much more widely adopted. That can't happen by ONLY doing the same things we've done for the last decade.

I think for the latter statement to happen, you may need to embrace users who want things to work as installed - to a certain extent anyway. If distros like SMEserver and ClearOS (where the common services work out of the box with task-oriented web administration) turn into SIGs, it may help. Likewise for any other special-purpose respins that reduce the setup work and knowledge needed to get a working configuration. The base OS as a toolbox is great for people who want to build something new, but not so much for those who just want to run some already-included services without caring a lot about the implementation details.

And if we do that, it will be in a SIG ... the SIG can create a LDAP/SMB active directory server pre-configured that has working postfix and DNS, etc.

That would be radically changed from the Core OS ... so people would have to opt in to either get that repo or that variant (depending on how it is packaged).

But we change do that at all if we don't allow a mechanism for that change to happen to things outside the Core OS.

On 06/09/2014 04:33 PM, Akemi Yagi wrote:

On Mon, Jun 9, 2014 at 7:33 AM, Jim Perrin jperrin@centos.org wrote:

...

RH providing (some of) us with a paycheck has simply meant we have more time to focus on the distribution instead of having late-night coffee-fueled work sessions after the family's gone to bed.

You really meant s/instead of/in addition to/ . (wicked grin)

........*SIGH*....yes ma'am...

On 06/08/2014 12:10 AM, Kay Williams wrote:

...

On Friday, June 06, 2014 5:44 PM, Karanbir Singh wrote:

hi,

Taking on board the community and environment expansion that is taking place around the CentOS project, the CentOS Board has been considering how best to accomodate these efforts.

I'm attaching here a plan put forward by the board towards that aim.

Thoughts ? Comments ?

Is the primary driver for the new versioning scheme the ability to expose SIG repos in the installer at a rate that differs from the RHEL release schedule?

If so, seems like we could address this by coding up the new installer UI (whatever it is) to allows new repos to come along at varying rates and automatically appear in the UI.

Then we get the best of both worlds - new SIG repos when they are ready, and compatibility with the RHEL versioning scheme.

No?

I am also against changing core versioning number.

Question: Have you decided to add repository files of SIG's into the main ISO/repository? I am not aware of that. If you ARE gpoing to create core distro different from RHEL releases, adding ALL repositories for EVERY SIG, then X.YYMM can be accepted as versioning scheme.

BUT, if you plan to keep core distro sterile, comparable with RHEL, then current versioning scheme must be kept in place, since it will be the mirror of the RHEL releases.

If SIG's can keep up with released updates of core distro, then there is no need to change their versioning either. They will just release updated packages at the time of core release, or just add older package in their own repo, which I am assuming will have priority over base/os/updates repositories, so any later core version will work also.

But, as far as I can see, real problem will be that SIG's will be needing NEWER packages then provided in core distro, so again that package will be provided in their higher priority repository, and it will be totally irrelevant what version core distro is.

It looks like we are again coming back to the issue of priorities of the various repositories and their hierarchy that I think should be incorporated into core distro by setting sane priority values (properly separated) and mandatory installation of "yum-plugin-priorities" package. Or at least to provide "centos-release-with-priorities" in Extras repository that will replace "centos-release" and demand that "yum-plugin-priorities" is installed.