根据 https://www.kernel.org/ 目前LTS分支有 4.4 4.9 4.14 4.19 5.4 5.10
2.x的分支不建议再维护了，没有DTS，增加了driver开发的复杂程度，而且存在安全漏洞
“支持期十年 二十年”恕难苟同，硬件必然在迭代，产品必然也有其生命周期，强行维护没有意义
综上，对LTS的分支支持，我是赞同的，其分支的新增和弃用，建议跟随上游
| |
ylliu3788
|
|
ylliu3788@163.com
|
签名由网易邮箱大师定制
在2021年7月24日 09:53，Netroby 写道：
大家好，我也是一名开发者，也一直关注着鸿蒙系统的开发和进展。
@李传钊 大佬分享的观点很有建设性意义。
我也反思，咱们该如何把社区建设，开发指南这些机制做好。 如果各位有建设性的意见，也可以一起分享出来。。
找到问题，不足，我们反馈出来，这肯定是很好的。
但是在这个基础之上，我们能提供解题思路。能提供解决难题的方案。那更是功德无量。
以下观点，仅抛砖引玉：
目前做的好的Linux kernel， 我们可以看到他们有 LTS 分支和 mainline的划分
就是如果你的业务，是不关注新特性，新功能，那么是可以选用LTS 分支，我知道很多公司还在用2.x的内核。。。 因为它太稳了。。
如果在这个基础上，有精力，那么可以跟一跟 mainline版本。。
鸿蒙也可以参考这一点。看是不是可以做支持。
软件迭代开发是肯定要做的，开拓创新，积极进取。
但是也不能说，我自己飙车，爽就完事了。 那这样其他小伙伴跟不上你的节奏，那这个游戏还怎么玩。
跑的快 的继续跑。但是也要有关照跑的慢的同学。
所以我以为解决开发者对鸿蒙跑太快了的顾虑，可能就是拿一个LTS方案。。 LTS分支，
API固定，保证兼容，不经常大改架构。但是会修复性能缺陷，安全漏洞等。支持期可以是十年，二十年。
这样开发者就不会担心，我怎么一个星期没看到代码，就完全看不懂了？？
我相信以华为强大的技术实力，一天做一百个变更，是可以的。是小菜一碟。但对于第三方开发者，可能就要哭晕了。。。这怎么学，怎么跟得上嘛。
Appreciate your time.
----------------------------
Netroby
dongjinguang 于2021年7月24日周六 上午9:09写道：
传钊 你好
非常感谢你反馈的这些问题，对OpenHarmony的推广和生态建设都是非常有建设性的建议，初步计划下周二晚上我们组织内核、驱动框架、海思芯片平台等的相关专家一起对这些问题和建议进行研讨，诚邀你能一起参与讨论和交流。
________________________________
董金光 Dong Jinguang
Mobile: +86-50000008869(For Welink,eSpace Calls)
Email: dongjinguang@huawei.com
发件人：962030 <962030@qq.com>
收件人：dev
时 间：2021-07-23 20:43:42
主 题：[Dev] 社区刚刚发布的开发板移植指导文档，我有话说
各位，
刚刚看到社区新发布的移植指导文档，我认为其内容偏离真实的三方开发板移植工作，是在缺乏真正的开发板移植经验的情况下写出的。
我有如下问题：
1.LiteOS-a移植过程中不需要考虑芯片的差异？不需要仔细阅读芯片手册？
2.LiteOS-a移植过程中不需要进行内存映射的计算和设计？
3.LiteOS-a移植过程中不需要考虑启动过程，与uboot的衔接？
4.Standard系统要求大家尽量采用4.19内核，这在大多数场合下是做不到的。
5.Standard系统对图形部分DRM毫无涉及，难道这块不用管就能跑起来？OpenHarmony的代码能适配所有芯片？
6.Standard系统的移植不需要调整rc？
第三方芯片移植是一个极其重要，对于OpenHarmony有生死意义的工作，期间涉及到的技术内容，即使写一本书，都不嫌罗嗦，建议重视此文档的持续改进。
另外目前的第三方芯片移植仍旧是困难重重，OS与kernel，OS与芯片的耦合现象仍旧十分严重，此问题暴露已久，大家要想出办法来，别再掩耳盗铃了！！！
也请邮件组中的各位老板，你们仔细了解一下移植的难度，忙着点赞的同时也客观评价一下工作的进度。大家都是做技术出身的，你们都知道远离技术的真相是多么可怕的事情。
李传钊 2021.7.23
________________________________
962030@qq.com
_______________________________________________
dev mailing list -- dev@openharmony.io
To unsubscribe send an email to dev-leave@openharmony.io
_______________________________________________
dev mailing list -- dev@openharmony.io
To unsubscribe send an email to dev-leave@openharmony.io
