给 sing-box 提交 XHTTP 实现后 PR 被关闭且账号被 Block，想请教是哪里做错了
先说明一下，发这个帖子不是想挂人，也不是要求项目必须合并我的代码。
我只是第一次遇到这种情况：花时间实现了一个功能、补测试和文档、修完 CI ，随后 PR 在没有任何评论的情况下被关闭，之后发现自己的 GitHub ID 似乎也被该项目 Block 了。
因为没有收到原因，所以想把时间线和技术背景完整写出来，请有开源项目维护经验的 V 友帮我看看，问题可能出在哪里。
项目：SagerNet/sing-box
PR：[https://github.com/SagerNet/sing-box/pull/4326](https://github.com/SagerNet/sing-box/pull/4326)
PR 标题：feat(xhttp): add XHTTP transport
### 时间线：
1. 7 月 17 日开始实现 sing-box 的 XHTTP transport 。
2. 7 月 22 日 14:34 左右整理并提交主要实现，包括：
- XHTTP 客户端和服务端
- stream-one 、stream-up 、packet-up 等模式
- HTTP/1.1 、HTTP/2 、h2c
- Xray 兼容配置字段
- xmux 、padding 、download settings 等功能
3. 14:35 左右补充生命周期测试、协议测试以及与外部 Xray-core 可执行文件的互操作测试。
4. 14:37 创建 PR #4326 。
5. PR 创建后发现 CI/Lint 有格式问题，于是根据 CI 输出修正并重新推送。
6. 14:58 推送 lint 修复。之后 GitHub Actions 中 Linux 、Windows 、macOS 、Android 各平台的 Lint 和 Test 都通过了。
7. 15:23 ，PR 被项目维护者直接关闭。
8. PR 页面没有 review 、没有 comment ，也没有说明不接受该功能的原因。之后我发现自己的账号似乎也无法再与该项目正常互动，表现像是被 Block 。
这里也把可能有争议的技术背景说清楚。
XHTTP 最初来自 Xray-core 。Xray-core 使用 MPL 2.0 ，sing-box 使用 GPLv3-or-later 。
我的实现参考过 Xray-core 的公开源码和协议行为，并不是严格意义上的 clean-room implementation 。这一点我愿意如实披露。
但实现本身使用的是 sing-box 的 Dialer 、TLS 、transport handler 和 Go net/http 架构，没有导入或链接 Xray-core 。互操作测试也是把 Xray 当成外部程序运行。
事后检查新增代码和 Xray splithttp 源码，没有发现明显的连续代码块复制。不过我确实在 config.go 里写过一句：
“ The implementation is independent from Xray-core.”
现在回头看，这句话不够准确。虽然代码是按 sing-box 架构重新实现的，但既然开发时阅读和参考过 Xray 源码，就不应该把它描述成完全独立或 clean-room 。我愿意修改这句话，也愿意根据要求补充来源说明、版权声明或 MPL 文件级许可信息。
据我目前查到的资料，MPL 2.0 是文件级 copyleft ，而且在没有 Exhibit B 排除的情况下可以通过 MPL 2.0 §3.3 与 GPLv3 项目组合。也就是说，即使部分文件被认定为 Xray 的派生实现，通常也应该是对相关文件补充 MPL 来源和许可义务，而不是整个 sing-box 被“污染”。
当然，许可证理解如果有错误，也欢迎指出。
我能想到 PR 被拒绝的原因包括：
- 上游根本不准备支持 XHTTP ；
- PR 体量太大，提交前应该先开 issue 讨论；
- 维护者不接受参考其他项目源码的实现；
- 对代码来源、AI 辅助或许可证存在疑虑；
- 实现方式不符合项目方向；
- 我之前的 “independent” 表述让维护者对来源产生了不信任；
- 还有我没有注意到的社区规则或历史问题。
这些理由中的任何一个，如果维护者明确说明，我都可以理解：项目是维护者的，他们当然没有义务合并任何 PR 。
我真正困惑的是，在 CI 已经通过、PR 没有争吵、没有 review 对话的情况下，为什么会直接关闭并疑似 Block ，而没有留下一句原因。
所以想请教大家：
1. 阅读其他 MPL 2.0 项目的源码后，使用 GPL 项目自身架构重新实现兼容协议，通常应该怎样声明来源？
2. 这种规模的功能是否应该先开 issue ，得到维护者确认后再实现？
3. PR 中那句 “independent from Xray-core” 是否严重到足以让维护者直接失去信任？
4. 从维护者角度看，还有哪些常见原因会导致无评论关闭 PR 并 Block 提交者？
再次说明，我发帖不是要求维护者必须合并，也不希望大家去 PR 下留言或打扰项目。
如果确实是我的提交方式、来源说明或者许可证处理有问题，我愿意承认并改正。我只是希望弄明白原因，避免以后再次踩同样的坑。
---
原文链接：[点击查看](https://www.v2ex.com/t/1229097)
我只是第一次遇到这种情况：花时间实现了一个功能、补测试和文档、修完 CI ，随后 PR 在没有任何评论的情况下被关闭，之后发现自己的 GitHub ID 似乎也被该项目 Block 了。
因为没有收到原因，所以想把时间线和技术背景完整写出来，请有开源项目维护经验的 V 友帮我看看，问题可能出在哪里。
项目：SagerNet/sing-box
PR：[https://github.com/SagerNet/sing-box/pull/4326](https://github.com/SagerNet/sing-box/pull/4326)
PR 标题：feat(xhttp): add XHTTP transport
### 时间线：
1. 7 月 17 日开始实现 sing-box 的 XHTTP transport 。
2. 7 月 22 日 14:34 左右整理并提交主要实现，包括：
- XHTTP 客户端和服务端
- stream-one 、stream-up 、packet-up 等模式
- HTTP/1.1 、HTTP/2 、h2c
- Xray 兼容配置字段
- xmux 、padding 、download settings 等功能
3. 14:35 左右补充生命周期测试、协议测试以及与外部 Xray-core 可执行文件的互操作测试。
4. 14:37 创建 PR #4326 。
5. PR 创建后发现 CI/Lint 有格式问题，于是根据 CI 输出修正并重新推送。
6. 14:58 推送 lint 修复。之后 GitHub Actions 中 Linux 、Windows 、macOS 、Android 各平台的 Lint 和 Test 都通过了。
7. 15:23 ，PR 被项目维护者直接关闭。
8. PR 页面没有 review 、没有 comment ，也没有说明不接受该功能的原因。之后我发现自己的账号似乎也无法再与该项目正常互动，表现像是被 Block 。
这里也把可能有争议的技术背景说清楚。
XHTTP 最初来自 Xray-core 。Xray-core 使用 MPL 2.0 ，sing-box 使用 GPLv3-or-later 。
我的实现参考过 Xray-core 的公开源码和协议行为，并不是严格意义上的 clean-room implementation 。这一点我愿意如实披露。
但实现本身使用的是 sing-box 的 Dialer 、TLS 、transport handler 和 Go net/http 架构，没有导入或链接 Xray-core 。互操作测试也是把 Xray 当成外部程序运行。
事后检查新增代码和 Xray splithttp 源码，没有发现明显的连续代码块复制。不过我确实在 config.go 里写过一句：
“ The implementation is independent from Xray-core.”
现在回头看，这句话不够准确。虽然代码是按 sing-box 架构重新实现的，但既然开发时阅读和参考过 Xray 源码，就不应该把它描述成完全独立或 clean-room 。我愿意修改这句话，也愿意根据要求补充来源说明、版权声明或 MPL 文件级许可信息。
据我目前查到的资料，MPL 2.0 是文件级 copyleft ，而且在没有 Exhibit B 排除的情况下可以通过 MPL 2.0 §3.3 与 GPLv3 项目组合。也就是说，即使部分文件被认定为 Xray 的派生实现，通常也应该是对相关文件补充 MPL 来源和许可义务，而不是整个 sing-box 被“污染”。
当然，许可证理解如果有错误，也欢迎指出。
我能想到 PR 被拒绝的原因包括：
- 上游根本不准备支持 XHTTP ；
- PR 体量太大，提交前应该先开 issue 讨论；
- 维护者不接受参考其他项目源码的实现；
- 对代码来源、AI 辅助或许可证存在疑虑；
- 实现方式不符合项目方向；
- 我之前的 “independent” 表述让维护者对来源产生了不信任；
- 还有我没有注意到的社区规则或历史问题。
这些理由中的任何一个，如果维护者明确说明，我都可以理解：项目是维护者的，他们当然没有义务合并任何 PR 。
我真正困惑的是，在 CI 已经通过、PR 没有争吵、没有 review 对话的情况下，为什么会直接关闭并疑似 Block ，而没有留下一句原因。
所以想请教大家：
1. 阅读其他 MPL 2.0 项目的源码后，使用 GPL 项目自身架构重新实现兼容协议，通常应该怎样声明来源？
2. 这种规模的功能是否应该先开 issue ，得到维护者确认后再实现？
3. PR 中那句 “independent from Xray-core” 是否严重到足以让维护者直接失去信任？
4. 从维护者角度看，还有哪些常见原因会导致无评论关闭 PR 并 Block 提交者？
再次说明，我发帖不是要求维护者必须合并，也不希望大家去 PR 下留言或打扰项目。
如果确实是我的提交方式、来源说明或者许可证处理有问题，我愿意承认并改正。我只是希望弄明白原因，避免以后再次踩同样的坑。
---
原文链接：[点击查看](https://www.v2ex.com/t/1229097)
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
2. 其实给这种项目提大 Feature 之前，最好先发个 Issue 跟作者沟通一下，免得白费功夫。
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞