I2P 开发者会议 - 2020年4月7日

22:04:29 <eyedeekay> 大家好，谁在这儿？ 22:04:40 <eche|on> 冒个泡 :-=) 22:04:46 <zlatinb> 嗨 22:04:48 <zzz> 到 22:06:18 <eyedeekay> 好的，第一个议题，0.9.46，zzz 请开始。 22:06:52 <zzz> 正在收尾对 ratchet（密钥棘轮，proposal 144）近两个月的工作 22:07:16 <zzz> 我差不多完成了“第 2 阶段”，此时功能已齐备 22:07:32 <zzz> 接下来会进入更多的修复和测试 22:07:51 <zzz> 所以 46 会让更多人来测试它，也许我们会在 47 中默认启用 22:08:23 <zzz> 之后我会把精力转向其他修复和话题，比如 streaming（Streaming 子系统，和 zlatinb 合作） 22:08:56 <zzz> 我这边 EOT，或许其他人可以说说他们在为 46 做什么 22:09:01 <eche|on> 我在两天前刚升级到 -5，仍然工作良好，包含了 tunnel 补丁的轮转，目前未见明显变化 22:09:56 <zlatinb> 我一直在反复阅读 TCP 的 RFC，注意到我们在 streaming 和 SSU 实现里有许多不一致。因此我把它们重写了。工单在 trac 上 22:10:24 <eche|on> 非常非常细致的阅读和检查，zlatinb 22:11:34 <eyedeekay> 我已经开始着手修改 i2ptunnel 的 UI，以减少我们呈现给新用户的不必要信息，并着手 i2ptunnel 的周期性密钥轮换机制 22:12:19 <eyedeekay> 我这边也有很多主线之外的工作，我想把 Firefox 配置包替换成也能在非 Windows 平台上工作的东西，这个进展得不错。 22:12:32 <eyedeekay> 大家就这些吗？ 22:12:46 <eche|on> 看起来是。 22:12:49 <eyedeekay> 另外，大家有问题吗？ 22:13:47 <eyedeekay> 到目前为止一切顺利。下一个是杂项 22:14:37 <eyedeekay> 关于 git 迁移，已经决定在下一个发布版*之后*而不是之前迁移 i2p.i2p。其他仓库可能会视情况更早迁移。 22:15:06 <eche|on> 好 22:15:20 <eyedeekay> git.idk.i2p 上的注册已开放，但需要管理员手动批准。我们会及时处理，但如果你着急，尽管来找我。 22:16:46 <eyedeekay> 目前推荐通过 SSH 使用 git，除了首次 clone——你可以用 snark 下载 git bundle 来完成。 22:16:50 <eyedeekay> EOT 22:17:18 <eyedeekay> 关于 git 迁移，有什么要问我的？ 22:17:31 <eche|on> 将 trac 工单纳入的进展如何？ 22:17:49 <eyedeekay> 我还没时间处理 tracboat，所以还没有。 22:17:58 <eche|on> 好 22:18:41 <zlatinb> 我有两个关于迁移的问题： 22:18:41 <zlatinb> 1. 在 git clone 期间，有没有办法修改 ssh 的网络读取超时？如果可以，把它增加到大约 5 分钟会提高成功率 22:18:41 <zlatinb> 2. 由于 trac 一直不太可靠，是否可以开始在 GitLab 上新建或镜像工单？这些会被关注吗？ 22:19:15 <eyedeekay> 1：我一直在调查这个，看起来不行，但我还不能给出确定答复。 22:19:20 <zzz> 关于第 2 点）如果你指的是 i2p.i2p，我不会看。 22:19:25 <eche|on> 关于第 2 点：tracboat 会是把所有 trac 工单纳入 git 的脚本化方案 22:19:54 <zzz> 相关问题：对 meeh 运营的对外公共服务持续偏低的在线率，有什么改进计划？ 22:20:02 <eche|on> 哦，抱歉，我是说复制/迁移现有工单。新工单也许是个问题 22:20:18 <zlatinb> 工单编号会保留吗？如果会，已经在 GL（GitLab）上开的工单怎么办，需要删除吗？ 22:21:21 <eyedeekay> 如果我能让迁移正常运行，工单编号应该会保留。重复的工单需要在其中一个工单关闭时手动删除。 22:22:08 <zlatinb> 如果迁移因任何原因无法进行，备选方案是什么？ 22:23:12 <zzz> 我们尚未就迁移 trac 达成一致；我认为这些都还只是实验。我建议把 trac 迁移推迟到所有 mtn（Monotone）分支（包括那些尚未上 GH（GitHub）的）都迁到 git 之后 22:23:33 <zzz> 也许最早 9 月 22:23:42 <eche|on> 对此的答案会和 zzz 的问题相关，目前没有固定计划。我的想法是让 trac 继续运行，保留旧工单 22:24:02 <eyedeekay> 我没法修好 trac，把工单迁走是我个人唯一能做的。如果不能用 tracboat 迁移，我就得自己动手。我熟悉 gitlab 那一侧，只需要学习 trac 那一侧。我知道 gitlab 看起来是替代 trac 的显而易见且诱人的选择，但这存在实质性的阻碍。 22:24:03 <zlatinb> 好的，那么在尝试迁移之前，我们是否继续使用 trac？ 22:24:41 <eyedeekay> 是 22:24:51 <eche|on> 关于工单：在工单迁移完成之前，请继续使用 trac 22:24:53 <zzz> 那么，谁负责修复 meeh 的那些服务？或者我们已经放弃了，正在着手替换他运行的所有东西？如果我们就是这么做的，那就请明确说明 22:25:56 <eche|on> meeh 负责他自己的服务。trac 应该被 git 取代。 22:26:31 <zzz> 但这并不能解决其他服务（比如 deb 仓库和 outproxy（出口代理））的系统性问题 22:26:31 <eche|on> Debian 仓库目前还是一个开放的事项，我做了一个镜像，但现在还需要更多时间把它按预期搭好 22:27:32 <eche|on> outproxy 我完全不会碰 22:27:50 <eyedeekay> 我乐意帮忙替换 meeh 的 deb 仓库，但对 outproxy 我无能为力。 22:29:19 <eche|on> meeh 常说问题主要在于他用的是旧 IP 上的老系统；随着 welterde 更改 DNS，这点在今天已经改变了 22:29:33 <zzz> 我认为，某个分支 X 的工单迁移只会在我们把 X 从 mtn 迁到 git 之后进行 22:29:35 <eche|on> 但目前还不确定 22:30:55 <eyedeekay> zzz 是的 22:31:08 <eyedeekay> 关于工单迁移 22:31:27 <eyedeekay> 这样就不会让大家困惑问题到底在哪里讨论。 22:32:21 <eyedeekay> 还有别的吗？ 22:34:22 <eyedeekay> 超时：60s 22:36:22 <eyedeekay> **Bafs** 好的，感谢各位参加