<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">My comment was targeted more at naming
      than support.<br>
      <br>
      I appreciate that there are vanishingly few resources to throw at
      support.<br>
      <br>
      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.<br>
      I try to help out when I can but it is all too infrequently.<br>
      <br>
      <br>
      On 01/21/2016 10:29 AM, Johnny Hughes wrote:<br>
    </div>
    <blockquote cite="mid:56A0F970.9040103@centos.org" type="cite">
      <pre wrap="">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:
</pre>
      <blockquote type="cite">
        <pre wrap="">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 
<a class="moz-txt-link-freetext" href="http://someplace.org/riskey-development/xen.repo">http://someplace.org/riskey-development/xen.repo</a> then your getting what
you ask for.


On 01/21/2016 08:09 AM, President wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:dunlapg@umich.edu"><dunlapg@umich.edu></a>
    *Sent:* Thursday 21st January 2016 7:32
    *To:* Discussion about the virtualization on CentOS
    <a class="moz-txt-link-rfc2396E" href="mailto:centos-virt@centos.org"><centos-virt@centos.org></a>
    *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 <a class="moz-txt-link-rfc2396E" href="mailto:peter@pajamian.dhs.org"><peter@pajamian.dhs.org></a> 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 <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Choice_of_Toolstacks">http://wiki.xen.org/wiki/Choice_of_Toolstacks</a> for information on
    other alternatives, including xl which is designed to be a drop in
    replacement for xm (<a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/XL">http://wiki.xen.org/wiki/XL</a>).
    ---

    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
    <a class="moz-txt-link-abbreviated" href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a>
    <a class="moz-txt-link-freetext" href="https://lists.centos.org/mailman/listinfo/centos-virt">https://lists.centos.org/mailman/listinfo/centos-virt</a>



_______________________________________________
CentOS-virt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a>
<a class="moz-txt-link-freetext" href="https://lists.centos.org/mailman/listinfo/centos-virt">https://lists.centos.org/mailman/listinfo/centos-virt</a>
</pre>
        </blockquote>
        <pre wrap="">

-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
<a class="moz-txt-link-abbreviated" href="mailto:alvin@netvel.net">alvin@netvel.net</a>              ||



_______________________________________________
CentOS-virt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a>
<a class="moz-txt-link-freetext" href="https://lists.centos.org/mailman/listinfo/centos-virt">https://lists.centos.org/mailman/listinfo/centos-virt</a>

</pre>
      </blockquote>
      <pre wrap="">

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
CentOS-virt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a>
<a class="moz-txt-link-freetext" href="https://lists.centos.org/mailman/listinfo/centos-virt">https://lists.centos.org/mailman/listinfo/centos-virt</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
<a class="moz-txt-link-abbreviated" href="mailto:alvin@netvel.net">alvin@netvel.net</a>              ||
</pre>
  </body>
</html>