[asterisk-dev] Proposal for DAHDI-trunk: deprecate old kernels
oron.peled at xorcom.com
Fri Dec 30 18:40:45 CST 2011
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:
> > 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.
Yes. The purpose of this discussion is to hear the thoughts of the
different parties involved (AFAIK there are Digium people on this
mailing list ;-)
[of course, also their unofficial opinions are most welcome as well]
> > * 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.
2. Please note that even RH themselves have very limited support
after 5 years - Refreshed hardware only via virtualization
Do you really imply that Digium should offer better hardware
support for RHEL than RH themselves?
> > 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
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).
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?
- 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 you think about the 7 years (what RH calls production 1,2,3)
than that will finish in two months.
What LTS plan should we have for an OS that finish its 7 years
regular support period in two months?
RHEL-4 users, that's the exact place we should here you SHOUTING!
What? I can't here you? Anybody there? Using trunk drivers?
Great, because we realy need RHEL-4 testers for our newest drivers
> 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.
You are right that we/Digium can wait until its 3 more "nuclear winter"
years pass. I argue that this is a bad decision.
Oron Peled Voice: +972-4-8228492
oron at actcom.co.il http://users.actcom.co.il/~oron
Q: What does FAQ stand for?
A: We have Frequently Asked this Question, and we have no idea.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-dev