GitHub 仓库突然收到大量 Stars，没找到原因……

[h404bi]

我维护的一个 scoop bucket 仓库： https://github.com/h404bi/dorado 在昨天访问量突然激增并被大量 star （虽然只是百来个，但不少了）。bucket 本来是自用为主，后来逐渐有其他 scoop 用户在用就维护着。除了此前在 v2 这里偶尔发过几次链接外，也没特别分享推广过。

仓库的 traffic 数据里也没有给出异常的 referral，突然来的找不到来源的 star，有点怂🤦‍♂️…

[heiybb]

https://twitter.com/D0nA1dJ0hNT3UmP/status/1251971144007077888

[heiybb]

@heiybb #1 点进 Thread 看，就有你这个 rep 的直链了
会不会是从这过去的
时间点也差不多能对上

[lostpg]

好评！

[h404bi]

@heiybb 谢谢谢谢，应该是，破案了。原来是 tweet 上被分享，链接在 traffic 里没有来源真不好排查。

[Jirajine]

有个小问题，你这个库里面有不少应用和官方库有重名的，不知道安装的时候 scoop 会装哪个？
个人觉得官方库里有的和通用的软件应该合并提交到官方仓库，这个库只单独维护一些本地化的软件即可。

[rosu]

仓库 insight — traffic 里有访问来源。

[h404bi]

@rosu 就是 traffic 里看不到有异常的 referral 才一脸懵逼😂

[h404bi]

@Jirajine 理论上应该是 main bucket 的权重是最高的，实际上 scoop 还没有做 bucket 权重的 feature，好像是按 bucket 克隆到本地后的名字按字母顺序先后查找 manifest 。我这个库里跟主库有重的原因有两个，一个是有些 package 是先于主库创建的，后面有其他用户加到主库里了。另一个原因是有些 package 我觉得主库的 manifest 写得不太好影响使用，就自定义了一份。有想过给重复的 manifest 改名，但是改名 /删除都会影响 end users，所以一般只增不减。

[Jirajine]

@h404bi scoop 这个不完善就有点坑，不但你维护时需要重复不必要的工作，还可能因更新不及时、版本差异造成其他难以排查的 bug 。
我觉得还是得尽早解决，比如给重名的应用发布更新标记为 deprecated 提示用户并 suggest/depend 对应主仓库的包或改名后的自己的修改包让他们迁移，不然时间长了历史包袱越来越重就很麻烦了。

[h404bi]

@Jirajine 我用了 5 年 scoop 了。其实除了 bucket 的一些问题外，scoop 还有不少其他方面的问题。不过还好不是非常严重，核心功能还是很好用的，而且一些问题 backlog 也被解决掉了。scoop 的开发活跃度不高，问题只能慢慢处理啦。

[fangxing204]

我在 Twitter 上看有人推荐你这个的

[BenX]

好像昨天有个群里讨论了这个，顺手点了一个 star