非常感谢您的回复和建议。W是lwip，是一个用户态的协议栈
这部分对W的侵入式修改完全是为了项目G，推社区比较困难。W对外部是透明的，不会影响其他组件或引起多版本问题。这部分可以抽取作为一个软件包，但是这会导致G被拆分，这是我们不希望的。
我的计划： lwip源码作为项目G的一部分，项目G全源码归档到openEuler。=》G稳定后发布 G-1.0.0.tar.gz =》在src-openEuler中归档 G-1.0.0.tar.gz + G.spec
作为一个开发者，我希望G和W能够以全源代码的方式归档到openEuler里。这样我可以直接基于git clone后的代码仓进行开发。 否则可能我拿到G的release包后，还需要执行一些操作（如打patch）才能够拿到G的所有源码。 很希望openEuler能认可这种方式：）。如果不ok的话，我就以源码包+patch的方式归档
------------------ 原始邮件 ------------------ 发件人: "Hexiaowen (Hex, EulerOS)" <hexiaowen@huawei.com>; 发送时间: 2020年7月11日(星期六) 上午10:32 收件人: "Hubble_Zhu"<hubble_zhu@qq.com>;"dev"<dev@openeuler.org>;"community"<community@openeuler.org>;"tc"<tc@openeuler.org>;
主题: [Tc]
你好，openEuler非常欢迎你的加入，
关于源码归档，建议还是遵循社区规范，采取upstream 的源码压缩包 + 补丁+spec的方式，方便追溯。
如果是自研的软件，release一个全源码的版本就行了。
对于G、W如何集成到openeuler中来，这边给一些自己个人的建议：
1、 侵入式修改是否足够通用，是否能够推入upstream社区，如果满足这两点，可以TC评审接纳W及其侵入式修改
2、 嵌入式修改的范围有多大，如果小范围的，影响可控的话，问题不大；如果比较大，能否开关控制
3、 侵入式修改是否可以抽离作为单独的软件包，如果可以问题就变得很简单
4、 实际上，是有部分软件，在编译和运行时，直接将w集成在自己的代码仓和运行目录下，同时要做好隔离，避免影响系统其它组件，但这也会带来系统中多版本的问题
期望我的回答对你有所帮助
overweight @gitee
Tel : +86 18042018786
Email : hexiaowen@huawei.com
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
发件人: Hubble_Zhu [mailto:hubble_zhu@qq.com] 发送时间: 2020年7月11日 0:39 收件人: dev <dev@openeuler.org>; community <community@openeuler.org>; tc <tc@openeuler.org> 主题: [Tc] 对引入新特性的代码归档格式询问
各位openEuler的成员，大家好，
我有一个项目G想申请在openEuler上开源，这个项目G高度依赖第三方开源包W，对W有一些侵入式修改。现在我是以源码的方式将开源包W的代码归档在项目G仓中
请问下如果开源到openEuler上的话，是否和W相关的代码，我都需要以源码包+patch的方式归档，或者我可以沿用全源码归档的方式？
采用全源码归档的方式对开发者很友好。
我计划是当项目G稳定并realease发行版后，在src-openEuler里新建仓库并添加spec来打成rpm包。
Any help will be greatly appreciated. thanks.