CentOS - Dec 2015 - Version numbering vis a vis CentOS and RHEL

OK, I'm staring a new thread.

On Mon, Dec 7, 2015 at 9:53 AM, Timothy Murphy <gayleard at eircom.net>
wrote:
> Phelps, Matthew wrote:
>
> >> > Oh, wait: CentOS, love it or leave it.
> >>
> >> Correct.
> >>
> >> In fact, I would prefer you leave.
> >
> > Really?
> >
> > This is what we're dealing with now?
> >
> > OK. I will recommend we move away from CentOS.
>
> This seems to be raising what to me is a trivial issue
> to an absurd level of hostility.
> Johnny Hughes' comment was uncharacteristically harsh;
> and yours is even harsher.
>
> To me, CentOS is a highly stable OS for my home servers,
> and I am eternally grateful to Johnny Hughes and his colleagues
> for carrying out what looks to me like an impossibly complex task.
>
> The numbering of packages is a very small part of this.
> On the other hand, a kernel panic would be very worrying to me
> if it were in fact likely to happen.
> I am glad to hear that I have no need to worry.
>
To you, and probably a majority of CentOS users, the "version number"
of
CentOS is indeed a trivial, cosmetic issue.

However, there are those of us who use CentOS in a very large enterprise
environment. That is, in fact, the intended audience of the whole distro.
When there is a "new version" of Red Hat (and I know that means
nothing
with hundreds of constantly updating packages; however, my bosses don't get
that),  and hence CentOS, there is a huge amount of work that needs to be
done in a typical enterprise. These include, but are not limited to:

- setting up a new internal-only mirror of the distribution
- setting up a new tftp/PXEboot/kickstart environment for network installs.
- Editing several install scripts to match the new environment
- Testing all these changes
- Checking that all security recommendations/edicts from a higher authority
(e.g. the US Government), which are also based on the "version", are
followed
- Checking that all commercial software supports the release (most of these
use "RHEL X.y", what is that in CentOS now?)
- Trying to get support from commercial software when the "version
numbers"
don't match
- Coordination of other repositories (e.g. EPEL) is based on the
"version",
how does that work now?

All of these things ran in parallel with the RHEL release cycle, and the
work could be done at the same time. That was the overriding philosophy of
CentOS, "we are a recompile of RHEL." Now, the impression is (rightly
or
wrongly, it doesn't matter to me) CentOS is totally becoming a separate
Linux distro, and needs to be treated as such. And that has huge
implications for system administrators in a large environment. Huge.

There are answers to all these questions, but there is a lot of confusion
that's been generated by this seemingly cosmetic change in version numbers.
I've checked, and there was no,"We're considering creating this
basic
difference from RHEL, how will this affect you?" on this list, or the
website, etc. From our viewpoint, it was sprung on us out of nowhere, and
now were being told "deal with it, or leave."

It sucks.


-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu

On Mon, 7 Dec 2015, Phelps, Matthew wrote:
> - Coordination of other repositories (e.g. EPEL) is based on the
"version",
> how does that work now?
Exactly the same as it did before.  Before you'd have a $maj.$min repo,
which
is the same as it is now.  maj=7 min=1.1503

You can park it there and not suffer any problems as I understand it.  At
least that's what I've done with 7.  So when 7.2 finally hits, it'll
be maj=7
min=2.1512
> All of these things ran in parallel with the RHEL release cycle, and the
> work could be done at the same time. That was the overriding philosophy of
> CentOS, "we are a recompile of RHEL." Now, the impression is
(rightly or
> wrongly, it doesn't matter to me) CentOS is totally becoming a separate
> Linux distro, and needs to be treated as such. And that has huge
> implications for system administrators in a large environment. Huge.
I don't see it as an issue.  A partially updated (without touching CR) 7.1.X
is equivalent to a partially update 7.1 RHEL.
> There are answers to all these questions, but there is a lot of confusion
> that's been generated by this seemingly cosmetic change in version
numbers.
> I've checked, and there was no,"We're considering creating
this basic
> difference from RHEL, how will this affect you?" on this list, or the
> website, etc. From our viewpoint, it was sprung on us out of nowhere, and
> now were being told "deal with it, or leave."
To me, I'm not sure I get any issues or advantages from the new scheme, but
I
can't say it bothers me greatly.

jh

1. Thank you, Matthew, for a new thread. This had nothing to do with the o/p
        of the old thread.
2. I'm not sure what more can possibly be said that hasn't already. Can
we
        end this, unless the Board decides to solicit our opinion, and
        get back to solving issues?
3. Board of CentOS: some folks don't care about the numbering, but it
bothers
        a *lot* of us, and at least to me, that doesn't seem like a huge
deal
        to change; it's not something critical to the distro. Therefore,
I'm
        politely asking you to revisit the issue in your meetings, and
        reconsider the x.y.# (e.g., 7.1.1511).

       mark, still struggling with bareos and windows

On 07/12/15 15:52, John Hodrien wrote:
> To me, I'm not sure I get any issues or advantages from the new scheme,
> but I
> can't say it bothers me greatly.
This is the thing that bothers me most - that folks dont have a good
grasp on what / why the numbering is working like this.

We are still a small team, and all efforts are flat out on getting the
iso media and images done, out of the door - but as soon as I have this
done, I'll look at hosting some google hangouts, irc sessions and maybe
a longer email thread as well to lay out the numbering proposition.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc