<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 10/12/2012 01:44 AM, Dag Wieers wrote:
    <blockquote
      cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
      type="cite"><br>
      Ok, this boils down to having potentially 3 kernels installed
      'kernel', 'kernel-lt' and 'kernel-ml'.</blockquote>
    You are perfectly correct here, potentially, yes, all three variants
    could be installed in the same time. But OTOH the kernel-lt is
    intended for people who do not want the latest major version so
    probably they would not install kernel-ml in the same time. I assume
    ( but of course, I might be wrong) that people would chose between
    these two lines of kernels depending on their intent. <br>
    However I really do not see the problem here. Yes, if one decides to
    install more than one kernel variant, one has to take care of all.
    Just like it would do with a single one. By definition all the
    kernels coming from elrepo come with a disclaimer. Which will affect
    all kernels that do not come from main+updates. no matter if there
    is one or there are more variants.<br>
    <br>
    <br>
    <blockquote
      cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
      type="cite"> If you switch from one to the other you have to
      manage those sets of packages. For 'kernel' I don't care, that's
      upstreamn, but what's the added benefit of having kernel-lt and
      kernel-ml ?
      <br>
    </blockquote>
    <br>
    The difference between -lt and -ml boils down to the difference that
    kernel.org makes between stable and long-term. And making sure that
    during an update ( a simple yum update, not necessarily a yum update
    kernel-ml ) the higher versioned kernel-ml packages would not
    inadvertently remove the lower-versioned-but-fancied-by-the-admin
    version. The name change is just a way of helping users to use the
    3.0 line without forcing them to use specific includes/excludes in
    the repo definition files.<br>
    <br>
    <br>
    <br>
    <blockquote
      cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">&gt;&nbsp; Besides, we do not influence when
          a release becomes stable, and when it &gt;&nbsp; not
          <br>
          &gt;&nbsp; longer is updated. So keeping all under the generic
          'mainline' brand is &gt;&nbsp; much
          <br>
          &gt;&nbsp; clearer.
          <br>
        </blockquote>
        <br>
        I beg to differ. When time comes we can simply switch to
        kernel-lt-4.0.1 instead of 3.0.x. Keeping ALL kernels below the
        kernel-ml generic name is exactly the thing which would confuse
        potential users looking for the 'long term stable' version (
        whatever version the upstream kernel.org people decide it to be
        )
        <br>
      </blockquote>
      <br>
      The paragraph before we assumed people knew what they were doing,
      and now we don't ?
      <br>
      <br>
      But that's not how it works. Stable kernels come and go, you have
      a few of those stable kernels in parallel. That's what the
      upstream kernel.org people have decided. Currently the following
      stable trees exist:
      <br>
      <br>
      &nbsp;- 3.0 (at 3.0.45)
      <br>
      &nbsp;- 3.2 (at 3.2.31)
      <br>
      &nbsp;- 3.4 (at 3.4.13)
      <br>
      &nbsp;- 3.5 (at 3.5.6) -&gt; ending
      <br>
      &nbsp;- 3.6 (at 3.6.1)
      <br>
    </blockquote>
    You forgot 2.6.32 and 2.6.34 :) ..... Actually there are no less
    than 8 trees marked as "stable" at <a class="moz-txt-link-abbreviated" href="http://www.kernel.org">www.kernel.org</a><br>
    We are not discussing stability here ( we all <strike>presume</strike>
    hope that the kernels that we get are stable, don't we? [*] ) but
    long-term maintenance.<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote
      cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
      type="cite">Stable release suddenly stop. Alan decides what
      versions ELRepo provides, but 'kernel-lt' is a bit shortsighted
      IMHO.
      <br>
      <br>
      Besides, what is confusing are 2-letter acronyms. Tell me, what is
      more confusing, one 2-letter acronym, or two, or four ?
      <br>
    </blockquote>
    Fine. Then let's call it kernel-mainline-supported-until-2014
    instead of kernel-lt :)<br>
    Seriously speaking now, that's why we are discussing. kernel-lts was
    suggested as a name exactly because LTS already has a known
    connotation. Your idea of creating sub-repositories is a possible
    alternative. I do not like it ( just like I hated the two sets of
    php packages from dev.centos.org ... nobody knew how to get them )
    but that's just me. Let's hear other opinions as well.<br>
    <br>
    <br>
    &nbsp;&nbsp;&nbsp; manuel<br>
    <br>
    <br>
    * about stability:
    <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=863422">https://bugzilla.redhat.com/show_bug.cgi?id=863422</a><br>
  </body>
</html>