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

[Tilghman Lesher]

On Thu, Dec 29, 2011 at 3:35 PM, Oron Peled <oron.peled at xorcom.com> wrote:
> On Thursday, 29 בDecember 2011 20:08:21 Jason Parker wrote:
>> On 12/29/2011 11:42 AM, Oron Peled wrote:
>> > * After DAHDI-2.8:
>> > Drop support for 2.6.18 kernels.
>>
>> I was with you right up until this point. If support for 2.6.18 is
>> released
>> before the enterprise distros maintenance period ends (RHEL5, March 2014),
>> then we are doing a serious disservice to these users.
>
> 1. You are right (and I knew RHEL/Centos-5 would be the thorniest
> issue), but let's try some prediction (although it's hard
> to make predictions... especially about the future ;-)
>
> * DAHDI-2.6 is out RSN.
>
> * I was talking about two releases ahead (2.7, 2.8) when would
> it be? Let's say they would take a year from now (we can
> be optimistic) [Jan-2013]
>
> * So let's re-evaluate RHEL-5 at that time.
> (how many such boxes would need *new* installtion from trunk
> not a maintenance release from DAHDI-2.8 stable branches)
>
> * "Worst" case, by that time we'll decide to wait until
> March-2014 as you suggested -- I'll be totally OK with this.
>
> * So it looks that 2.6.18 kernels can be deprecated sometime
> around 2013, 2014.
>
> 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/
>
> "...No new functionality, new hardware support or updated
> installation images..."
>
> So we talk about extending DAHDI *trunk* support beyond
> the time the OS vendor itself supports new hardware install.
>
> * 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.

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).

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.

-Tilghman