Replies: 5 comments 13 replies
-
|
Umm 看起来不错，但是合并之前应该还是需要大致 Review 一下，主要是防止一个功能进去拿下一整个启动器... 对快照版内容的处理我觉得没啥问题 |
Beta Was this translation helpful? Give feedback.
-
|
umm 我会把和其他功能耦合的部分简单 review 一下，不耦合的部分先直接丢进去，这样应该风险不大（ |
Beta Was this translation helpful? Give feedback.
-
|
社区其实可以帮助 Review 的（ |
Beta Was this translation helpful? Give feedback.
-
不如社区帮助 Review，如果社区觉得没问题就加进去，等到正式合并龙猫再正式 Review？ |
Beta Was this translation helpful? Give feedback.
-
|
社区能帮忙 review 自然是更好 orz |
Beta Was this translation helpful? Give feedback.
-
|
我个人并不介意快照版内容提前于正式版公开，相信社区里也有许多和我想法一样的用户，此问题应该在更广范围内征求其他内群用户的意见。 “尝鲜特性”的设想在实际操作时应该会面临各种各样的问题，但作为进一步迈向社区化的一项举措，似乎值得一试。 然而，本文中提到的两个提案似乎互相冲突，不知道是不是我理解错了。 如果“尝鲜特性”的代码会被合并到发布版本，同时仓库的基底是正式版的，那么这就会使仓库的代码成为四不像，既不是快照版（基于正式版）又不是正式版（有“尝鲜功能“）。大概会很混乱。 |
Beta Was this translation helpful? Give feedback.
-
|
不知道我说明白了没有，我认为问题就在这里：在公开仓库 Merge PR 后，仓库的代码就既不是快照版也不是正式版，而是“正式版+尝鲜特性”，也就是产生了第三种版本。 |
Beta Was this translation helpful? Give feedback.
-
|
那把公开仓库的 PR Merge 放到正式版发布、代码同步前，这样就能避免这个问题……？ |
Beta Was this translation helpful? Give feedback.
-
|
应该可以，不过这会不会导致尝鲜功能先出现在正式版再出现在快照版？ |
Beta Was this translation helpful? Give feedback.
-
|
除非遇到紧急情况，为了避免严重 bug 造成大范围影响，正式版总是在快照版之后出的，所以应该没有这个问题（ |
Beta Was this translation helpful? Give feedback.
-
|
大致懂了 |
Beta Was this translation helpful? Give feedback.
-
|
umm 此外，现在新功能制作进度缓慢的重要原因之一是，我一大半的时间都得用于处理小 bug 和小优化。有时候还会出现连续修几个月 issue，新功能压根没空做的情况…… |
Beta Was this translation helpful? Give feedback.
-
能写的现在似乎都在忙着折腾社区版的 PR/Issue 和代码解耦....... 基本忙的不可开交 |
Beta Was this translation helpful? Give feedback.
-
坐和放宽，社区最近也有很多新人进来帮助开发的，以及社区版积攒的 Issue 很多也是主仓库有的 |
Beta Was this translation helpful? Give feedback.
-
|
确实是，但修小 bug 和写小优化可能还是比较难，因为可能搞不清这一部分的运行逻辑，无法定位问题和决定解决方案位置。 |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
还对逆向后的源码有一定了解是吧。 |
Beta Was this translation helpful? Give feedback.
-
由于合并 PR 需要重写代码，所以大型 PR 合并速度一直很慢。我在寻思能不能这样整：
如果一个 PR 与现有代码的耦合度较低，可以将该 PR 先行合并，暂不进行 Code Review 。然后，在该功能页面上加入一条提示横幅，告知该功能是由社区开发的尝鲜特性，且可能存在稳定性问题。
对于此类尝鲜特性的相关 issue，不添加优先度标签，而是添加一个新的
🚧 尝鲜特性标签，它们会推迟到对该功能进行 Code Review 时进行统一处理。这样的话，至少 PR 不会一直挂在这里挂上个大半年……
此外，关于公开的代码以及 fork 导致快照版内容被提前公开的问题，我可以把仓库代码改为在每次正式版发布时进行同步，这样就 OK 了？
这些目前是我的想法， 并非最终决定 ，如果大家有更好的方案可以在这里提出，在达成共识后会重新发正式的公告 :D
Beta Was this translation helpful? Give feedback.
All reactions