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

[Tilghman Lesher]

Please stop CC'ing me on every reply.  I read the mailing list; when
you CC me on each reply, I get two copies of the message.

On Fri, Dec 30, 2011 at 6:40 PM, Oron Peled <oron.peled at xorcom.com> wrote:
> On Friday, 30 בDecember 2011 01:55:42 Tilghman Lesher wrote:
>> On Thu, Dec 29, 2011 at 5:34 PM, Oron Peled <oron.peled at xorcom.com> wrote:
>> > * 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.
>
> 1. Expecting a single driver suite (DAHDI-trunk) to actually "support"
> a 10 years span of kernel development (2.4-3.2) is....
> "interesting" but not very realistic.

If the choice is made not to have LTS releases (and this is the same
as making no choice at all, the de-facto option), then this is exactly
what would need to happen.  The point that we need to make is that the
pain of such is significantly higher than the pain of maintaining an
LTS release of DAHDI.

> 2. Please note that even RH themselves have very limited support
> after 5 years - Refreshed hardware only via virtualization
> [https://access.redhat.com/support/policy/updates/errata]

We're not talking about refreshed hardware, though.  We're talking
about software updates to continue supporting existing (legacy)
hardware.  Yes, when Digium releases a new hardware board 1 year from
now, it is ridiculous to assume that that hardware will be supported
by the DAHDI 2.5 branch.  If you want the latest hardware, you've got
to use the latest release, and then you are restricted to the kernels
that that release supports.  But if you've got existing hardware, you
should be able to expect that the drivers for that hardware will
continue to get bugfixes in a way that remains compatible with your
running kernel.

>> > 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)
>>
>> I think you mean 2.6. DAHDI 2.5 was released in August. In any case,
>> we'd need for that kernel to be deprecated in a full release branch
>> before we remove it. So, yes, it would need to remain in 2.7, in
>> deprecated mode, if it were not already deprecated in 2.6. And we
>> would additionally need to declare DAHDI 2.6 to be an LTS release. If
>> it were deprecated in 2.6, then 2.5 would need to be the LTS release.
>
> 1. I actually meant after the comming DAHDI-2.5.x (0.3?), so that
> DAHDI-2.6.y would carry the deprecation warning and we can clean
> this code before DAHDI-2.7 release

Not possible, because release candidates have already gone out for
DAHDI 2.6 which continue to have non-deprecated support for 2.6.8
kernels.  If you want to deprecate a kernel version in a particular
release of DAHDI, it needs to be done before the first release
candidate of that branch.

> 2. The logic is because RHEL-4 ended "Production 2" phase almost a year
> ago (meaning no support for new hardware) and would end "Production 3"
> phase in two months (Feb-2012).

We're not talking about support for new hardware.  We're talking about
extended bugfixes for a particular DAHDI release in a fashion that has
heretofore not taken place.

> 3. While you are technically correct in your observation about the
> need to declare some stable DAHDI branch as LTS. The real
> question IMO is when to declare RHEL-4 *completely* unsupported?

That's going to depend upon Digium's paying customers.  If they have a
big client that continues to use RHEL-4 beyond 2015, then they're
going to keep supporting the related kernel in DAHDI (or a particular
LTS release of DAHDI) until that client either upgrades or the support
contract expires.

Now, I don't think the extended maintenance of DAHDI branches is going
to be that big of a deal, from a labor standpoint.  Bugfixes are
rarely in the older sections of code; they usually occur in newer code
that has gotten many less hours of production testing.  However, when
a bugfix is needed, it will need to be verified in each older
maintained release of DAHDI, which will take time and resources away
from writing new functionality.

> - If you think about the 10 years perioud (Feb-2015) than
> by the same token why not support RHEL-3 (its 10 years
> last until Jan-2014)

If there was a support contract in place at the time that required
DAHDI to support RHEL-3, I have little doubt that support for 2.4
kernels would not have been removed in DAHDI 2.0.  There weren't,
however.

>> As I noted before, given that Digium maintains the repository and the
>> packages, this is their decision. If they choose not to do LTS
>> releases for DAHDI, then I don't see any reasonable alternative other
>> than keeping support for 2.6.8 in all versions of DAHDI until after
>> the sunset date for RHEL-4.
>
> IMO the sunset has passed about a year ago (5 years), we are now in its
> late evening and in two months it would reach the time of midnight kiss.

At this point, it's more of a business decision based upon support
needs, and given the weekend (and federal holiday), nothing is likely
to be decided until Tuesday, the 3rd, at the earliest.

Happy New Year.

-Tilghman