On Mon, Mar 31, 2014 at 9:36 AM, Jim Perrin <jperrin@xxxxxxxxxx> wrote:
>
>
> On 03/31/2014 08:16 AM, Phelps, Matt wrote:
> > On Mon, Mar 31, 2014 at 8:58 AM, Jim Perrin <jperrin@xxxxxxxxxx> wrote:
> >
> >>
> >>
> >> On 03/31/2014 07:28 AM, Phelps, Matt wrote:
> >>> Initial reaction: Crap!
> >>>
> >>> One of the best things about CentOS, in my opinion, was not having to
> >> deal
> >>> with all the different RHEL builds/releases/whatever they called them,
> >> and
> >>> just having ONE distribution.
> >>
> >> This doesn't change. It's the core sig.
> >>
> >>
> > But the current "core" distribution has KVM/libvirt, and all the desktop
> > stuff, and apache, etc. etc, each of which sounds like it will be broken
> > out into a separate "SIG."
>
> No. The SIGs are community efforts where a newer or different version is
> needed. Core stays core.
>
> > Please, please don't do this. Let us do our jobs and pick what we need
> from
> > the same install depending on what kind of machine we're installing.
>
> This is exactly the intent. Right now there are a load of admins who
> want or need newer versions of things, be it php, python, libvirt, ruby,
> whatever. We're not changing up the core. We're trying to provide a
> better way to get updated features if they're needed.
>
> > I don't want to have to change our whole installation environment, which
> > we're take years of work to get the way we want it, based on someone
> else's
> > arbitrary rearranging of what's needed for "Storage" or "Virtualization,"
> > etc.
>
>
> You won't have to. Stick with core, and you'll be fine.
>
> >
> >>
> >>> So much for that.
> >>>
> >>> It didn't take long for Red Hat to get their mitts all over CentOS,
> huh?
> >>
> >> We were already doing this sort of thing with the Xen4CentOS build, and
> >> the plus repo before the RH agreement. We're simply able to expand on
> >> this type of effort now.
> >>
> >>
> > Both of those are additions to "CentOS." Please don't break up "CentOS"
> > arbitrarily into separate "products" like Red Hat needlessly did. Let us
> > pick and choose what we need easily.
> >
> > The whole point of an "Enterprise " environment is to minimize the change
> > so we don't have to re-tool everything.
>
> Yep, and the "C" has been for 'Community', which has been a driving
> force in this. Xen was in el5, and when it was dropped in el6 we had a
> large hosting user-base who suddenly had no upgrade path to the new
> version. By adding Xen support back in, we've provided a method for them
> to update without re-tooling. We're trying to keep the need to change
> minimal, exactly as you want.
>
> > (Sorry for all the sarcastic quotes, but I'm upset. This is exactly the
> > sort of meddling I was afraid of when Red Hat took over.)
>
>
> This seems a bit "the sky is falling" to me. We're not changing what
> we've done in the past. We're adding (entirely optional) functionality
> to meet the demands of the community. You don't have to change a thing
> if you don't want to.
>
>
>
>
OK, I'll calm down. Perhaps what you've said could have been communicated
by the article. This line is what troubled me:
"So what the newly united Red Hat and
CentOS<http://www.zdnet.com/red-hat-incorporates-free-red-hat-clone-centos-7000024907>
is
planning on are multiple CentOS releases."
How will these "SIGs" be handled? Just additional yum repos? What if I want
to use parts of the Storage SIG and Virtualization SIG together on the same
installation?
Thanks.
Oh, does this mean we'll get a working chrome/chromium past version 31? :)
--
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphelps@xxxxxxxxxxxxxxx, http://www.cfa.harvard.edu
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
