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

[Tilghman Lesher]

On Fri, Dec 30, 2011 at 7:59 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
> On Thu, Dec 29, 2011 at 05:55:42PM -0600, Tilghman Lesher wrote:
>> On Thu, Dec 29, 2011 at 5:34 PM, Oron Peled <oron.peled at xorcom.com> wrote:
>> > On Friday, 30 בDecember 2011 00:22:16 Tilghman Lesher wrote:
>> >> 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.
>>
>> Well, hang on a moment.  Since this does require Digium resources, we
>> will need their consent on whether or not they choose to support any
>> particular branch for an extended period.
>
> IANADE, but I'll point out that Digium's resources are also spent right
> now on supporting older kernels. Or rather: not really spent. From I
> recall, it took quite some time for build issues in 2.6.9 to be cought
> in the recent cycle of changes. I have no idea how extensively those
> older systems are actually geting tested with newer drivers (maybe they
> do get tested, but on newer stages, past development).
>
> I'll also point out that we already have such a LTS branch: Zaptel.
> "Branching" Zaptel was also used to get rid of support for 2.4 kernels
> (including RHEL 3).

Well, not really, because Zaptel didn't receive any bugfixes after the
point in time when DAHDI 2.0 was released.  An LTS release should get
bugfixes on a continuing basis, and Zaptel is certainly its own unique
situation, because of the trademark issue.  Continuing bugfix versions
of Zaptel would have continued the trademark violation, which is part
of the point of the name transition to DAHDI.  So I would not consider
Zaptel to be an LTS release of anything.

>> > * This means we normally have to maintain only a single LTS branch
>> > to bridge the final life-cycle of the previous RHEL version.
>>
>> That's not true, though, if the extent of the LTS release is anything
>> less than the full 7 or 10 years that Red Hat supports their release.
>> Otherwise, we will have an unsupported LTS release near the end of the
>> Red Hat release cycle, which again puts IT managers in a very
>> uncomfortable situation.
>
> Digium is commited to its customers. Not specifically to the RHEL
> support schedule. If Digium chooses to provide support for its customers
> for the full LTS schedule of RHEL, that's Digium's choice, which I fully
> respect.

Well, but many of those customers are on RHEL (or other enterprise
releases), so by extension, Digium supports what their (paying)
customers need them to support.

-Tilghman