-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
改善 mirror request 规则 #267
Comments
我觉得没有必要硬性规定支持人数达到一定门槛才能进入正式讨论。如果一个镜像的同步方法简单,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 <bojieli@gmail.com>
4th year Ph.D. student, USTC
Intern at Systems Research Group, Microsoft Research Asia
T2 #12330, No.5 Danling Street, Beijing, China
|
然而,我们的主要矛盾就是没空间了啊( #263
Bojie Li <notifications@github.com> 于 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>
.
|
我觉得指望大家申请新镜像时写清楚信息不是非常可行,一般用户可能并不清楚各种源的最合理同步方式,即使写了“源站是某某某”,或许只是个 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 基本不可行,中间涉及太多政策和管理问题,例如:
总体是个很好的想法,只可惜生错了地方。实际上 Debian 官方的 |
目前有一个独立的资源整合项目 mirrorz,收录了国内一些镜像
目前有个第三方域名 https://mirrorz.org 提供前端服务,同时有个后端 https://m.mirrorz.org 提供实验性后端(样例:https://m.mirrorz.org/archlinux ),暂无其他服务 对于 mirror request 的问题,感觉可以在 mirrorz 相关项目中发布/提出,有兴趣的镜像站可以进行参考,但mirrorz不对相关镜像站作出任何规约/保证 |
|
现在 mirrorrequest 那边挂着许多申请,也经常有人发邮件申请新增镜像,但多数都没有下文,一直把 issue 留在那里或者一直不回复邮件也不太好,我建议这样改善:
希望这些提议能征集到真正有需要的镜像,合理关闭那些没人 follow 的镜像申请,并改善镜像的删除规则~
The text was updated successfully, but these errors were encountered: