对于多任务的lua修复事件的一个回应

原贴如下：
https://www.bilibili.com/read/mobile/459519
在此对本贴中的几个说法进行一个回应。
①：「那个lua是我修复的，怎么没感谢我呢？」
我在这里不太想计较关于lua是谁写的这种问题，倒是说说这种心态的问题。首先，YGOPro以GPL 2.0协议开源，协议里面允许任何人对代码进行贡献，但是对代码贡献的人，无权要求把credit写上自己的名字。而且，代码流出去之后，就属于这个项目的一部分了，不存在这一段代码是是你的还是我的的问题。所以不太欢迎你这样计较代码的归属问题。
另外说一下有人反复戳我我问我有没有抄少年的代码的。这个我不管有没有抄，都跟你们没关系。凭什么不能抄？何况，KoishiPro乃至MCPro甚至圆神版的YGOPro，都有借鉴DevPro和EDOPro的代码。以及这些代码的原作者之一edo9300，都积极的为Mercury233和我和MyCard团队提供帮助，和可以修改提升的地方。开源精神就是如此，只有你这么计较这个问题。
另外，默默为YGOPro提供帮助的人很多，除了mercury233大家比较常见，还有夏娜，VanillaSalt，EricCode这些背后做文章的人。这些人都没有被感谢，也没有找麻烦。为什么只有你就开了一个具有Conflict的Pull Request，就说要感谢了？
②：「Conflict是Mercury233导致的，跟我没关系」
任何开Pull Request的人都有义务去维护自己的Pull Request。这也方便进行直接合并。出现Conflict的时候你几个小时了没有做出任何操作，自然会被当做是无效的Pull Request。
即使Mercury233修改了上游代码，你也应该进行立即的Conflict修复操作，确保你的代码永远都是可用的。你自己没有及时修复代码，这个期间还说要感谢，自然站不住脚。
③：「自己的一份努力被剥夺了」
为了保证版本库的提交是干净的。对Pull Request的合并采用的是Squash Merge，即把fork里面所有的commit合并为1个commit合并入版本库，来确保没有冗余提交。
因此，只是提交被合并了而已，并不是努力被剥夺了。因为Sauash Merge导致历史提交没有你的名字这个是完全正常的现象，请不要拿这个来说事。
④：「选择性忘记233服之后的通知」
说这个之前，先明确一个事情。
“官方”的YGOPro脚本库是https://github.com/Fluorohydride/ygopro-scripts
Koishi服务器的脚本库是
https://github.com/Smile-DK/ygopro-scripts，并严格和这个库同步。 2
233服的脚本库是官方脚本库的最新的发布版本，并不完全和官方脚本库同步，因为考虑到录像问题。
而每次release发布和233服更新的时候，更新的commit非常多（你可以用git history或者git diff看看），无法逐个统计哪张卡修改了，更难以统计谁改的哪张卡。自然很难通知到了。雪花更不会知道去查看ygopro-scripts的commit，就连目前mercury233用的ygopro-update.js都做不到，何况用人力统计了。所以没通知上这个也无可厚非，而不是所谓的「选择性遗忘」。
⑤：「7210非官方服务器，没有权威」
Koishi服务器一直是作为KoishiPro配套的服务器，有一些提前更新的卡可以给大家玩的。同时也是YGOProES和ADS使用的服务器。而且，既然在邮件出现了，那就是这期间就是有效的了。
何况，最近几次C盟比赛，使用的也都是Koishi服务器。而这里面有很多bug的修复，那么既然多任务可以用了，虽然没有很完善，但是总比有bug好，何乐而不为呢？
另外，现在Koishi服务器使用的脚本，除了提前更新的一些卡参照ygopro-pre-script以外，其他全部严格按照ygopro-scripts的来走。所以只是机子不同而已，其他没什么不同。
⑤：写在最后
●建议不要在谁贡献了什么这种比功劳的鸡毛蒜皮的事情太计较。YGOPro的是大家的，不是你用来玩过家家的。要真的对YGOPro有热心的话，不如低头老老实实做事情。commit的提交者自然能说明一切。
●说真的，YGOPro的repo的维护算是非常自由并且稳定的了。没有特别严格的权限管理，还特别稳定，没怎么闹过事。或许这就是开源的优点吧。不像C盟，权限划分的那么细，还老是这里闹事那里闹事。这说明YGOPro的开发组的素质是很高的。希望你能维持这一份宁静，不要去打破它。