各位openEuler的成员，大家好， 我有一个项目G想申请在openEuler上开源，这个项目G高度依赖第三方开源包W，对W有一些侵入式修改。现在我是以源码的方式将开源包W的代码归档在项目G仓中 请问下如果开源到openEuler上的话，是否和W相关的代码，我都需要以源码包+patch的方式归档，或者我可以沿用全源码归档的方式？ 采用全源码归档的方式对开发者很友好。 我计划是当项目G稳定并realease发行版后，在src-openEuler里新建仓库并添加spec来打成rpm包。 Any help will be greatly appreciated. thanks.
从目前 src-openeuler+ openeuler的设置来看，你的G和W适合全源代码归档到 openeuler里，然后稳定发布的时候再 压缩包+patch放到 src里面。 有个问题就是W是啥，是否已经在openEuler里面了。 W的修改会不会导致其他包的变化。 Hubble_Zhu <hubble_zhu@qq.com> 于2020年7月11日周六 上午12:42写道：
各位openEuler的成员，大家好，
我有一个项目G想申请在openEuler上开源，这个项目G高度依赖第三方开源包W，对W有一些侵入式修改。现在我是以源码的方式将开源包W的代码归档在项目G仓中 请问下如果开源到openEuler上的话，是否和W相关的代码，我都需要以源码包+patch的方式归档，或者我可以沿用全源码归档的方式？ 采用全源码归档的方式对开发者很友好。
我计划是当项目G稳定并realease发行版后，在src-openEuler里新建仓库并添加spec来打成rpm包。
Any help will be greatly appreciated. thanks.
_______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
非常感谢您的回复，我也很希望G和W能够以全源代码的方式归档到openEuler里 W是lwip，是一个开源的用户态协议栈，现在openEuler里面还没有。当前openEuler上也没有其他依赖W的软件包 我的计划： lwip作为项目G的一部分，项目G全源码归档到openEuler。=》G稳定后发布 G-1.0.0.tar.gz =》在src-openEuler中归档 G-1.0.0.tar.gz + G.spec 希望openEuler tc认可这种方式 ------------------ 原始邮件 ------------------ 发件人: "Chenye Liang" <liangchenye@gmail.com>; 发送时间: 2020年7月11日(星期六) 上午10:06 收件人: "Hubble_Zhu"<hubble_zhu@qq.com>; 抄送: "dev"<dev@openeuler.org>;"community"<community@openeuler.org>;"tc"<tc@openeuler.org>; 主题: [Tc] Re: 对引入新特性的代码归档格式询问 从目前 src-openeuler+ openeuler的设置来看，你的G和W适合全源代码归档到 openeuler里，然后稳定发布的时候再 压缩包+patch放到 src里面。 有个问题就是W是啥，是否已经在openEuler里面了。 W的修改会不会导致其他包的变化。 Hubble_Zhu <hubble_zhu@qq.com> 于2020年7月11日周六 上午12:42写道： 各位openEuler的成员，大家好， 我有一个项目G想申请在openEuler上开源，这个项目G高度依赖第三方开源包W，对W有一些侵入式修改。现在我是以源码的方式将开源包W的代码归档在项目G仓中 请问下如果开源到openEuler上的话，是否和W相关的代码，我都需要以源码包+patch的方式归档，或者我可以沿用全源码归档的方式？ 采用全源码归档的方式对开发者很友好。 我计划是当项目G稳定并realease发行版后，在src-openEuler里新建仓库并添加spec来打成rpm包。 Any help will be greatly appreciated. thanks. _______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
你好，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.
非常感谢您的回复和建议。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.
首先非常高兴你的项目希望能加入到openEuler中。你提出了一个很好的问题，确实是需要我们这个社区一起讨论一下的。比如类似你的项目这样的情况，lwip并不是只有你的这个项目需要，后面还有一个项目会基于LWIP来开发。因此，如何保证不同的项目基于同样的一个组件能够做到共存是一个需要一起讨论的问题。我先说一下基本的原则把： 1. 第一优先级是upstream first，也就是尽量贡献到上游社区，一旦能够合并入上游社区，那么很多问题就迎刃而解了。 2. 对于由于种种原因没有办法合并入上游社区的补丁，或者对某些公共部件有侵入式修改。openEuler社区是可以接受的。但是请依据如下的规则 2.1 侵入式修改，patch不影响组件本身的API，ABI，也就是不影响其它业务。类似这样的修改比如增加了一个api等。这样的修改经相关的SIG组讨论以后，由SIG决策是否合入。 2.2. 修改影响了API，无法满足兼容性要求。如果需要长期演进，而且相关协议允许，可以考虑单独fork出相关的项目，甚至改名，成为一个单独的组件。 2.3. 如果2.1， 2.2都不是，那么可以考虑你所提议的，在不违反license的基础上，和项目一起打包，但是需要明确安装路径等，不能和标准的组件的安装路径等冲突。 对于你的项目，openEuler社区刚刚成立了high-performance-network的SIG组，我建议你和这个SIG一起探讨lwip等这些应用广泛的网络组件的社区维护方式。谢谢。 在 2020-07-12 19:04:24，"Hubble_Zhu" <hubble_zhu@qq.com> 写道： 非常感谢您的回复和建议。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.
participants (4)
-
Chenye Liang -
Hexiaowen (Hex, EulerOS) -
Hubble_Zhu -
myeuler