My comment was targeted more at naming than support. I appreciate that there are vanishingly few resources to throw at support. I am glad to see any xen support for C7 and am thankful of all those who are putting in time to make things happen. I try to help out when I can but it is all too infrequently. On 01/21/2016 10:29 AM, Johnny Hughes wrote: > This is a community SIG .. and xenproject.org does NOT release XSAs for > 4.2. The goal of Xen4centOS was to use an upstream LTS kernel and > update those as required to stay on an LTS. Also to do every second > point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term > than upstream, BUT we have supported code from upstream. > > So, the goal is to use supported code for the longest amount of time the > upsreams support them. For xenproject.org .. they support the two > newest releases. For kernel.org, they do a new kernel LTS about every 2 > years. > > We don't have 5000 engineers to maintain community SIGs like they > maintain the distro. We have to have supported code from upstream projects. > > On 01/21/2016 07:46 AM, Alvin Starr wrote: >> Its my impression that as a general rule from RH once some software has >> been released into a major release any further release of that software >> does not change major version or fundamental features.. >> >> For C6 I would argue Xen 4.2 should stay packaged as xen and Xen 4.4 be >> packaged as xen44 ... >> I do not believe that Xen has been released for C7 yet so what ever >> package version is released should be xen and others should be xen4x. >> >> It provides consistency for those who expect it and upgrading for those >> who need it. >> >> Looking at a C7 with epel added. >> I can see python, python2 and python3. >> >> On the other hand If your picking xen up from >> http://someplace.org/riskey-development/xen.repo then your getting what >> you ask for. >> >> >> On 01/21/2016 08:09 AM, President wrote: >>> RE: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in >>> centos-virt-xen-testing >>> >>> My .02 is to stay the course. As a server admin, I want to be able >>> to type things like: >>> >>> >>> yum upgrade php >>> >>> not >>> >>> yum upgrade php55-epel-rpmforge-fancy-package >>> >>> >>> Having to remember all the idiosyncrasies of a system is what causes >>> some type of major failure in the future whenever (1) you forget >>> something or (2) someone else has to pick up the box to adminster. >>> >>> >>> >>> -- >>> >>> Craig Thompson, President >>> >>> Caldwell Global Communications, Inc. >>> >>> +1 (423) 559-5465 >>> >>> caldwellglobal.com >>> >>> >>> -----Original message----- >>> *From:* George Dunlap <dunlapg at umich.edu> >>> *Sent:* Thursday 21st January 2016 7:32 >>> *To:* Discussion about the virtualization on CentOS >>> <centos-virt at centos.org> >>> *Subject:* Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages >>> available in centos-virt-xen-testing >>> >>> On Thu, Jan 21, 2016 at 12:01 PM, Peter <peter at pajamian.dhs.org> wrote: >>> > On 15/01/16 05:57, George Dunlap wrote: >>> >> As mentioned yesterday, Xen 4.6 packages are now available for >>> >> testing. These also include an update to libvirt 1.3.0, in line with >>> >> what's available for CentOS 7. Please test, particularly the upgrade >>> >> if you can, and report any problems here. >>> > >>> > Per conversation in IRC, Xen 4.6 no longer includes xend and therefore >>> > no longer has the "xm" command. This is problematic for people who may >>> > be using xm in various scripts on their host (such as home-brewed backup >>> > scripts). >>> > >>> > I think it's a bad idea to break this functionality without warning by >>> > allowing a simple "yum update" to remove it. You will take a lot of >>> > people by surprise and cause such scripts to stop working, if people are >>> > running yum cron the situation becomes even worse. >>> >>> Thanks, PJ, for your input. >>> >>> Just to be clear: >>> >>> 1. In the Xen 4.4 packages (first released October 2014), xend was >>> disabled by default; so anyone using xend at the moment has already >>> manually intervened to enable deprecated functionality >>> >>> 2. In 4.4, the first time xm was executed, it printed this warning: >>> --- >>> xend is deprecated and scheduled for removal. Please migrate to another >>> toolstack ASAP. >>> >>> See http://wiki.xen.org/wiki/Choice_of_Toolstacks for information on >>> other alternatives, including xl which is designed to be a drop in >>> replacement for xm (http://wiki.xen.org/wiki/XL). >>> --- >>> >>> 3. ...and on every subsequent invocation, it printed this warning: >>> "WARNING: xend/xm is deprecated" >>> >>> I think this constitutes "warning" that the functionality was going to >>> break at some point. :-) >>> >>> Also, in most cases "s/xm/xl/g;" Just Works; most people have reported >>> that changing from xm -> xl was pretty painless. So this isn't like >>> upgrading from Python 2 to Python 3 (or QT 4 to 5, or...). >>> >>> > I think that due to this lack of backwards compatibility with Xen 4.4 >>> > and earlier versions it would be a good idea to not force the upgrade on >>> > people who are not wary of it. I propose that the new packages carry >>> > the name "xen46" and they purposefully conflict with the old "xen" >>> > packages. That will require people to take positive action to do the >>> > upgrade and hence avoid breaking systems unintentionally. >>> >>> This would avoid breaking things for people still using xm, which >>> certainly has some value. However it has some costs: >>> >>> * The packages between C6 and C7 will now be slightly different, >>> increasing the maintenance burden. This is not only in the spec file, >>> but also in all the associated scripting machinery for managing >>> packages in the CBS and smoke-testing packages before pushing them >>> publicly. >>> >>> * Instructions for installing Xen are now differend between C6 and C7, >>> and slightly more complicated, as they have to explain about Xen 4.6 >>> vs alternatives. >>> >>> * Users who have heeded the warning and switched to xl will have to >>> make an extra effort to switch to Xen 4.6. If they don't follow >>> centos-virt, they may not notice that there's a new package to upgrade >>> to. >>> >>> I'm a developer, not a server admin, so I can't gauge how important >>> this issue is. Before making such a change, I'd like to hear opinions >>> from other people in the community about how important (or not) it is >>> to avoid breaking xm, given the ample warning (>1 year) users have >>> had. >>> >>> On the other hand, explicitly moving to a "xen${VER}" (both for C6 and >>> C7) would make it simpler for people to step up and maintain older >>> versions in parallel if anybody wanted to do so. >>> >>> Thanks again, Peter, for bringing this up. >>> >>> Peace, >>> -George >>> _______________________________________________ >>> CentOS-virt mailing list >>> CentOS-virt at centos.org >>> https://lists.centos.org/mailman/listinfo/centos-virt >>> >>> >>> >>> _______________________________________________ >>> CentOS-virt mailing list >>> CentOS-virt at centos.org >>> https://lists.centos.org/mailman/listinfo/centos-virt >> >> -- >> Alvin Starr || voice: (905)513-7688 >> Netvel Inc. || Cell: (416)806-0133 >> alvin at netvel.net || >> >> >> >> _______________________________________________ >> CentOS-virt mailing list >> CentOS-virt at centos.org >> https://lists.centos.org/mailman/listinfo/centos-virt >> > > > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > https://lists.centos.org/mailman/listinfo/centos-virt -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin at netvel.net || -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20160121/f9571490/attachment-0006.html>