On Mon, Mar 31, 2014 at 9:36 AM, Jim Perrin <jperrin at centos.org> wrote: > > > On 03/31/2014 08:16 AM, Phelps, Matt wrote: > > On Mon, Mar 31, 2014 at 8:58 AM, Jim Perrin <jperrin at centos.org> 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 at cfa.harvard.edu, http://www.cfa.harvard.edu