改善 mirror request 规则

[SmartHypercube]

现在 mirrorrequest 那边挂着许多申请，也经常有人发邮件申请新增镜像，但多数都没有下文，一直把 issue 留在那里或者一直不回复邮件也不太好，我建议这样改善：

1. 明确一个进入正式讨论的门槛，如需要 3 或 5 个用户，通过描述自己接触到相关项目的渠道、实际需求、使用该项目的现状等，体现出自己对该镜像有真实需求。达到这个门槛后我们才处理相关申请。因为建镜像的目的是让大家使用，如果建了后没人用，就没有意义花力气调研、配置、维护。
2. 找一种方法清晰地向大家传达出这个规则，并且容易按当前联名申请的实际用户数量排序查看所有申请。现在基于点赞标志的投票方式比较随意，既不易计算真实用户数，也不易排序查看（虽然能做到）。然而具体什么方法比较好，我还没想清楚，大家有何高见？我想到的一个可行的做法是继续使用 issues 讨论，规定发言第一行只包含“支持”二字即表明自己是在作为真实用户支持，用 webhook 和 GitHub API 收集信息，另外做一个“当前排名”网页来展示投票情况。机器人也可以在任何新 issue 被创建后立刻发表一条评论，描述投票规则并给出一个链接，点开能看到这个镜像当前的票数情况，方便大家使用。
3. 对于达到了门槛的申请（应该就不会很多了，所以我们会更有意愿去调研一下可行性），应当确保跟进处理，处理起来有困难的应当回复解释。
4. 开启后一定时间内，如 3 个月，都没有达到门槛的申请，不需要调研或回复，直接关闭。
5. 不时根据 Nginx 日志等信息分析镜像使用情况，如果镜像消耗资源较多且看起来没人用了，可以进行删除投票。删除投票是给”不删“这个选项投票，规则和新增镜像相同，如果一段时间后投票数不足就删除。为了让大家知道正在进行删除投票，避免不知道的情况下镜像就被删了，或许可以先停止该镜像的服务，但保留配置和数据，投票到达一定数量立刻恢复，或者过期后真正删除。

希望这些提议能征集到真正有需要的镜像，合理关闭那些没人 follow 的镜像申请，并改善镜像的删除规则~

[bojieli]

我觉得没有必要硬性规定支持人数达到一定门槛才能进入正式讨论。如果一个镜像的同步方法简单，issue 提出者已经给出上游地址，所需存储资源较少，没有版权问题，哪怕没有人附议，也可以把该镜像添加进去。毕竟对我们维护者来说，增加一个镜像并没有很多开销。 此外，目前 mirror request 里面大量的 open issue 中镜像同步方法不明确，或者使用方法不明确。应当在 README 里鼓励 issue 的提出者指出明确的同步方案，能够顺便提供该镜像的使用方法更好，这样维护者只是做一个审核和录入同步脚本的工作，就轻松很多。

…

On Wed, Feb 27, 2019 at 12:40 AM Hypercube ***@***.***> wrote: 现在 mirrorrequest 那边挂着许多申请，也经常有人发邮件申请新增镜像，但多数都没有下文，一直把 issue 留在那里或者一直不回复邮件也不太好，我建议这样改善： 1. 明确一个进入正式讨论的门槛，如需要 3 或 5 个用户，通过描述自己接触到相关项目的渠道、实际需求、使用该项目的现状等，体现出自己对该镜像有真实需求。达到这个门槛后我们才处理相关申请。因为建镜像的目的是让大家使用，如果建了后没人用，就没有意义花力气调研、配置、维护。 2. 找一种方法清晰地向大家传达出这个规则，并且容易按当前联名申请的实际用户数量排序查看所有申请。现在基于点赞标志的投票方式比较随意，既不易计算真实用户数，也不易排序查看（虽然能做到）。然而具体什么方法比较好，我还没想清楚，大家有何高见？我想到的一个可行的做法是继续使用 issues 讨论，规定发言第一行只包含“支持”二字即表明自己是在作为真实用户支持，用 webhook 和 GitHub API 收集信息，另外做一个“当前排名”网页来展示投票情况。机器人也可以在任何新 issue 被创建后立刻发表一条评论，描述投票规则并给出一个链接，点开能看到这个镜像当前的票数情况，方便大家使用。 3. 对于达到了门槛的申请（应该就不会很多了，所以我们会更有意愿去调研一下可行性），应当确保跟进处理，处理起来有困难的应当回复解释。 4. 开启后一定时间内，如 3 个月，都没有达到门槛的申请，不需要调研或回复，直接关闭。 5. 不时根据 Nginx 日志等信息分析镜像使用情况，如果镜像消耗资源较多且看起来没人用了，可以进行删除投票。删除投票是给”不删“这个选项投票，规则和新增镜像相同，如果一段时间后投票数不足就删除。为了让大家知道正在进行删除投票，避免不知道的情况下镜像就被删了，或许可以先停止该镜像的服务，但保留配置和数据，投票到达一定数量立刻恢复，或者过期后真正删除。 希望这些提议能征集到真正有需要的镜像，合理关闭那些没人 follow 的镜像申请，并改善镜像的删除规则~ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#267>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWx4UCopl7r3zM-nNPUNXLc5nc9KgwNks5vRWNlgaJpZM4bSmzg> .

-- Bojie Li <[email protected]> 4th year Ph.D. student, USTC Intern at Systems Research Group, Microsoft Research Asia T2 #12330, No.5 Danling Street, Beijing, China

[cuihaoleo]

然而，我们的主要矛盾就是没空间了啊（ #263 Bojie Li <[email protected]> 于 2019年3月1日周五 19:48写道：

…

我觉得没有必要硬性规定支持人数达到一定门槛才能进入正式讨论。如果一个镜像的同步方法简单，issue 提出者已经给出上游地址，所需存储资源较少，没有版权问题，哪怕没有人附议，也可以把该镜像添加进去。毕竟对我们维护者来说，增加一个镜像并没有很多开销。 此外，目前 mirror request 里面大量的 open issue 中镜像同步方法不明确，或者使用方法不明确。应当在 README 里鼓励 issue 的提出者指出明确的同步方案，能够顺便提供该镜像的使用方法更好，这样维护者只是做一个审核和录入同步脚本的工作，就轻松很多。 On Wed, Feb 27, 2019 at 12:40 AM Hypercube ***@***.***> wrote: > 现在 mirrorrequest 那边挂着许多申请，也经常有人发邮件申请新增镜像，但多数都没有下文，一直把 issue > 留在那里或者一直不回复邮件也不太好，我建议这样改善： > > 1. 明确一个进入正式讨论的门槛，如需要 3 或 5 > 个用户，通过描述自己接触到相关项目的渠道、实际需求、使用该项目的现状等，体现出自己对该镜像有真实需求。达到这个门槛后我们才处理相关申请。因为建镜像的目的是让大家使用，如果建了后没人用，就没有意义花力气调研、配置、维护。 > 2. 找一种方法清晰地向大家传达出这个规则，并且容易按当前联名申请的实际用户数量排序查看所有申请。现在基于点赞标志的投票方式比较随意，既不易计算真实用户数，也不易排序查看（虽然能做到）。然而具体什么方法比较好，我还没想清楚，大家有何高见？我想到的一个可行的做法是继续使用 > issues 讨论，规定发言第一行只包含“支持”二字即表明自己是在作为真实用户支持，用 webhook 和 GitHub API > 收集信息，另外做一个“当前排名”网页来展示投票情况。机器人也可以在任何新 issue > 被创建后立刻发表一条评论，描述投票规则并给出一个链接，点开能看到这个镜像当前的票数情况，方便大家使用。 > 3. 对于达到了门槛的申请（应该就不会很多了，所以我们会更有意愿去调研一下可行性），应当确保跟进处理，处理起来有困难的应当回复解释。 > 4. 开启后一定时间内，如 3 个月，都没有达到门槛的申请，不需要调研或回复，直接关闭。 > 5. 不时根据 Nginx > 日志等信息分析镜像使用情况，如果镜像消耗资源较多且看起来没人用了，可以进行删除投票。删除投票是给”不删“这个选项投票，规则和新增镜像相同，如果一段时间后投票数不足就删除。为了让大家知道正在进行删除投票，避免不知道的情况下镜像就被删了，或许可以先停止该镜像的服务，但保留配置和数据，投票到达一定数量立刻恢复，或者过期后真正删除。 > > 希望这些提议能征集到真正有需要的镜像，合理关闭那些没人 follow 的镜像申请，并改善镜像的删除规则~ > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#267>, or mute the thread > < https://github.com/notifications/unsubscribe-auth/ABWx4UCopl7r3zM-nNPUNXLc5nc9KgwNks5vRWNlgaJpZM4bSmzg> > . > -- Bojie Li ***@***.***> 4th year Ph.D. student, USTC Intern at Systems Research Group, Microsoft Research Asia T2 #12330, No.5 Danling Street, Beijing, China — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#267 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2UDwGXqyfaY3M8AcsM5F20FX0Wnmvfks5vSROSgaJpZM4bSmzg> .

[SmartHypercube]

我觉得指望大家申请新镜像时写清楚信息不是非常可行，一般用户可能并不清楚各种源的最合理同步方式，即使写了“源站是某某某”，或许只是个 HTTP 或 FTP 地址，其实应该用 rsync。有的源可能还需要我们去发邮件联系，或者加入某个邮件列表/关注某个状态监视界面。并不容易从一个镜像申请看出添加这个镜像所需的额外工作量。

…

On Mar 1, 2019 19:48, "Bojie Li" ***@***.***> wrote: 我觉得没有必要硬性规定支持人数达到一定门槛才能进入正式讨论。如果一个镜像的同步方法简单，issue 提出者已经给出上游地址，所需存储资源较少，没有版权问题，哪怕没有人附议，也可以把该镜像添加进去。毕竟对我们维护者来说，增加一个镜像并没有很多开销。 此外，目前 mirror request 里面大量的 open issue 中镜像同步方法不明确，或者使用方法不明确。应当在 README 里鼓励 issue 的提出者指出明确的同步方案，能够顺便提供该镜像的使用方法更好，这样维护者只是做一个审核和录入同步脚本的工作，就轻松很多。 On Wed, Feb 27, 2019 at 12:40 AM Hypercube ***@***.***> wrote: > 现在 mirrorrequest 那边挂着许多申请，也经常有人发邮件申请新增镜像，但多数都没有下文，一直把 issue > 留在那里或者一直不回复邮件也不太好，我建议这样改善： > > 1. 明确一个进入正式讨论的门槛，如需要 3 或 5 > 个用户，通过描述自己接触到相关项目的渠道、实际需求、使用该项目的现状等，体现出自己对该镜像有真实需求。达到这个门槛后我们才处理相关申请。 因为建镜像的目的是让大家使用，如果建了后没人用，就没有意义花力气调研、配置、维护。 > 2. 找一种方法清晰地向大家传达出这个规则，并且容易按当前联名申请的实际用户数量排序查看所有申请。 现在基于点赞标志的投票方式比较随意，既不易计算真实用户数，也不易排序查看（虽然能做到）。然而具体什么方法比较好，我还没想清楚，大家有何高见？我想到的一个可行的做法是继续使用 > issues 讨论，规定发言第一行只包含“支持”二字即表明自己是在作为真实用户支持，用 webhook 和 GitHub API > 收集信息，另外做一个“当前排名”网页来展示投票情况。机器人也可以在任何新 issue > 被创建后立刻发表一条评论，描述投票规则并给出一个链接，点开能看到这个镜像当前的票数情况，方便大家使用。 > 3. 对于达到了门槛的申请（应该就不会很多了，所以我们会更有意愿去调研一下可行性），应当确保跟进处理，处理起来有困难的应当回复解释。 > 4. 开启后一定时间内，如 3 个月，都没有达到门槛的申请，不需要调研或回复，直接关闭。 > 5. 不时根据 Nginx > 日志等信息分析镜像使用情况，如果镜像消耗资源较多且看起来没人用了，可以进行删除投票。删除投票是给”不删“这个选项投票，规则和新增镜像相同， 如果一段时间后投票数不足就删除。为了让大家知道正在进行删除投票，避免不知道的情况下镜像就被删了，或许可以先停止该镜像的服务， 但保留配置和数据，投票到达一定数量立刻恢复，或者过期后真正删除。 > > 希望这些提议能征集到真正有需要的镜像，合理关闭那些没人 follow 的镜像申请，并改善镜像的删除规则~ > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#267>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABWx4UCopl7r3zM- nNPUNXLc5nc9KgwNks5vRWNlgaJpZM4bSmzg> > . > -- Bojie Li ***@***.***> 4th year Ph.D. student, USTC Intern at Systems Research Group, Microsoft Research Asia T2 #12330, No.5 Danling Street, Beijing, China <https://maps.google.com/?q=5+Danling+Street,+Beijing,+China&entry=gmail&source=g> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#267 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHbbND24JTTYQvMaSZH93cMu_saBHo4tks5vSROTgaJpZM4bSmzg> .

[wojiushixiaobai]

能否联合其他国内的兄弟学校一起来做这个事情？这可能需要一定的上级支持
如：

• 按照区域划分，进行资源整合

  • 华东
  • 华西
  • 华南
  • 华北
  • 海外

• 访问方式

  • 联合使用官方域名
    • 各子节点可以继续使用，资源使用重定向（还要考虑到校内使用问题，需要资源网络互通）

• 其他资源提供

  • 公共 DNS
  • 其他

• 其他资源整合

  • 云厂商
  • 域名厂商
  • 安全厂商
  • 其他

比起必须盈利的企业来说，他们可能很难去实现这个目标，但是对于学校来说，可能会相对容易些。
这种经验也很宝贵。

大致的想法是把这个当成一个试点项目来处理，如果能有效整合这些资源，可以去做更多的事情。

[iBug]

@wojiushixiaobai 基本不可行，中间涉及太多政策和管理问题，例如：

• 「联合使用官方域名」涉及到备案问题，特别是教育网备案还有额外的要求
• 每个学校有自己的管理方式和规章制度，不是所有学校都一样开放的，甚至有的大学镜像站还在为申请公开校外访问跟团委扯皮
• 「公共 DNS」等其他资源同样有类似的政策或合规性问题

总体是个很好的想法，只可惜生错了地方。实际上 Debian 官方的 ftp.xx.debian.org 也有很多是托管在第三方机构的（大学 / 企业），但是国内没这样的环境，很遗憾。

[ZenithalHourlyRate]

大致的想法是把这个当成一个试点项目来处理，如果能有效整合这些资源，可以去做更多的事情。

目前有一个独立的资源整合项目 mirrorz，收录了国内一些镜像

联合使用官方域名

目前有个第三方域名 https://mirrorz.org 提供前端服务，同时有个后端 https://m.mirrorz.org 提供实验性后端（样例：https://m.mirrorz.org/archlinux ），暂无其他服务

对于 mirror request 的问题，感觉可以在 mirrorz 相关项目中发布/提出，有兴趣的镜像站可以进行参考，但mirrorz不对相关镜像站作出任何规约/保证

[wojiushixiaobai]

@iBug

抱歉！这个其实是脑子一热，然后简单的思考了一下给出的答案。

我实际想说明的是最后一句话，把这个当成一个试点项目来处理，如果能有效整合这些资源，可以去做更多的事情。

虽然镜像站一开始可能只是方便校内外的同学访问，但随着口口相传😀的技能。不可否认的是 Ta 已经肩负了一定的社会责任；

在有限资源的情况下，其他的学校也会面临这样的问题，所以才有了这个想法「能否联合其他国内的兄弟学校一起来做这个事情？」

我上面提出的其实是我设想完成之后的样子（仅限于个人的想法）。
初期只是以这个问题为由，跟其他的兄弟学校一起沟通下提出一个这样的建议大家讨论讨论这样。
并不是一开始就向上面要政策要资金；形成一定的效应之后这些问题我想都能够很好的解决的。


上面的其他资源整合想法是这样的：
   目前国内的镜像源不少，常用的华为、阿里、腾讯、网易，加上国内的各大学。
   但是前者的维护力度明显小于后者，这与技术无关，更多的是利益问题。
   我的想法是能否由各大学高校牵头，这些云厂商出设备出环境，一起来做好这个事情（自愿原则下，有钱出钱有力出力）。 
   企业可能会由于各种利益问题不便展开更深入的技术交流合作，这其实限制了企业的发展，而且很多工作是在重复的造轮子...

当然，这也只是我个人的一些看法。当成试点是如果这能成为一个标杆项目，将为后续的其他合作打开一扇大门（如其他学科、甚至不限于学校的交流）。


还是把想写的写完吧，说不定哪天也忘了。
    这里后续的合作，比如国内针对不同年级的交流论坛（或社区，只是叫法不同，可以理解成类似 B 站的学术交流版本）；