[asterisk-dev] Proposal for DAHDI-trunk: deprecate old kernels

[Oron Peled]

On Friday, 30 בDecember 2011 00:22:16 Tilghman Lesher wrote:
> On Thu, Dec 29, 2011 at 3:35 PM, Oron Peled <oron.peled at xorcom.com> wrote:
> ...
> 2. However, the policy you imply has bigger, long term, implication:
> * First, RHEL life-cycle has separate periods, the March-2014
> date means until end of "Production 3 Phase". From:
>
> https://access.redhat.com/support/policy/updates/errata/
> > ...
> > * The more accute problem is that it implies maintaining
> >    DAHDI trunk for two RHEL releases (e.g: 5 + 6)
> >
> >    It is easy to see that this is not sustainable:
> >    - E.g: RHEL-4 + RHEL-5 (Feb-2005 until Mar-2014)
> >      spans 10 years
> >    - In this time the upstream kernel matured from 2.6.0
> >      into 3.x.... Hmmm...
> >
> > So while I think the current decisions are not very difficult
> > we are heading to some harder decisions later.
> 
> Yes, but we're talking about two very different life cycles.  Because
> we don't have long term support for any particular release of DAHDI
> (other than what may be required for LTS releases of Asterisk), we
> expect that users continue to transition to higher versions of DAHDI,
> when they need to upgrade to get bugfixes.  Consider that DAHDI 2.0
> was released just over 3 years ago, yet we hardly expect people to
> still be using DAHDI 2.0.  Once DAHDI 2.1 was released, no further
> releases were made to DAHDI 2.0, and so on up the line.

Correct.

> So to say that we're dropping support for any particular kernel in
> DAHDI, given historical norms, really means that people will be caught
> in an impossible situation:  either they will need to become
> proficient enough to backport bugfixes from newer versions to older
> branches that still have support for their enterprise kernels, or they
> will need to upgrade their enterprise systems earlier than expected
> (and budgeted for).

Agreed.

> The alternative is that we start giving DAHDI release branches more
> long term support, by creating LTS releases of DAHDI and supporting
> those kernels for an extended period.

Yes. Since no one here has the same resources RH can put into
maintaining their RHEL, this seems like the only resonable alternative.

Let's elaborate this for our current example:
   * Immediately after RHEL-6 was released, RHEL-5 still had very
     active life-cycle.

   * In that period, RHEL-5 should still be fully supported in trunk,
     so customers may still upgrade to the latest stable DAHDI if
     they want.

   * Few years later, this distro has passed both "Production 1" and
     "Production 2" -- for RHEL-5 this is Q4-2012 (next year).

   * We can than choose the latest DAHDI stable and mark it LTS
     (say DAHDI-2.8)

   * At that time, customers would have two options:
     - Stay in "Production 3" support (for RHEL-5, that's 2013-2014).
       DAHDI would have a stable supported (LTS) branch for them.
       However, RH would not support major new hardware and features,
       and the same would be true for this DAHDI release.

     - Move to RHEL-6 which would be 2 years old system at that time.

I think this plan (or similar) is feasible because it
requires bounded resources:
  * Each LTS branch should be maintained for 1.5-2 years:
    - No major changes, just bug-fixes or hardware support
      that does *not* require major changes.

  * The current release (e.g: RHEL-6) would be fully supported by
    trunk (and by extension, all branches in its time frame).
    This is just like it work today.

  * This means we normally have to maintain only a single LTS branch
    to bridge the final life-cycle of the previous RHEL version.

Note: I took RHEL/Centos as a prime example, but this can serve any
      "enterprise" distro (their release cycle is similar)

Last, but not least -- can we ring the bell on 2.6.8/9 (RHEL-4)
immediatly after DAHDI-2.5.x is released, so we can remove it
by February ? (no, I don't want to see this legacy in DAHDI-2.7)

Thanks,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"A billion flies _can_ be wrong - I'd rather eat lamb chops than shit."
        -- Linus Torvalds on lkml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111230/2e96e7dd/attachment-0001.htm>