[Feature] RFC: master quality improvement

[unicornx]

Describe problem solved by the proposed feature

RTT 仓库的 master 分支的稳定性问题我感觉是老问题了，能不能从软件工程角度解决一下？否则现在发现经常 sync 后 master 就build 不过，大量的时间花费在解决 bugfix 上，但这些是可以可以通过流程控制解决的呀。
我能想到的一些改进建议, 权当抛砖引玉，希望大家各抒己见，否则社区版本如果还是继续目前这个状态，至少我个人觉得会劝退不少想来做贡献的新人

Describe your preferred solution

• 建议措施（1）改进 CI，完善自动化测试用例集合

  确保 qemu 上可以跑的几款 bsp 能够得到有效看护。这样至少可以保证部分内核的 common 功能（譬如posix 系统调用）和 qemu 上的 bsp（驱动）可以在 master 上始终确保相对稳定。

• 建议措施 （2）增加小版本周期

  完善自动化测试用例，不涉及大量人工介入方式下覆盖有限几款重点看护的真机稳定性，这样至少可以保证部分内核的 common 功能（譬如posix 系统调用）和这些真机的 bsp（驱动）可以在 master 上始终确保稳定。如果自动化测试的周期足够短的话（假设一天？），我们可以每个周期（一周或者两周）预留一天暂停 master 合入，跑完测试后就打 tag，而且我觉得为了不 block master，即使有问题也打 tag，只是在对应 tag 上给出一个问题报告的说明并提出相应的 isseu进行跟踪。另外，重点看护的真机列表可以随时间进化。

  后来觉得，如果我们不想 block master 的合入，其实可以更激进一点，就是先打 tag，然后跑测试，如果没问题就标记整个 tag 稳定，如果有问题，就把 issue 提出来，tag 一样打上，只不过我们就知道这个 tag 是不稳定的。后面任何时候拿 master 使用发现出问题都可以回溯到最近的一个稳定的版本去继续开发。当然如果发现最近几次 tag 测试都有问题，那么负责 merge 的人也可以把控一下 merg的 节奏了。

• 建议措施（3）完善大版本周期

  一个月或者两个月，但不要再长了，投入较大人力做回归测试，覆盖更多的 bsp。其实这个已经不是我关注的重点了。

我提出以上的改进建议的目标：

• 尽量不改变现有流程的基础上（master 即开发分支），也尽量不 block master 的进展（顶多每个 tag 锁死一天不许 merge）。
• 通过（1）和 （2）改善 master 的稳定性。
• 虽然我们不能百分百保证 master 上的所有 bsp 都100%稳定，但是通过（2） 中提供的tag机制，我们可以在遇到 master 不稳定时，可以回退到最近的一个相对稳定的 tag 上继续我们的开发，而不会完全 block 住而且也不清楚 master 上的哪个 commit 才是可用的。

Describe possible alternatives

No response

[chenyingchun0312]

为啥不考虑一下git flow的版本发布模式?而是提到master分支的Block操作呢?

[unicornx]

为啥不考虑一下git flow的版本发布模式?而是提到master分支的Block操作呢?

没有看懂您的问题，可否详细描述一下你的建议？您说的 git flow 发布模式和我这个 issue 希望解决的问题是什么关系？

[supperthomas]

https://nvie.com/posts/a-successful-git-branching-model/
gitflow是一套比较成熟的开发流程，可以有效保证master上的节点的稳定性。大部分商用大公司会采用该套流程。
https://club.rt-thread.org/ask/article/0b3fdc34e31c7feb.html

[supperthomas]

bsp/cvitek 还没有加到CI里
https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/bsp_buildings.yml

[BernardXiong]

说下我的看法，以及历史：

分支类型

RT-Thread这边默认是把master做为开发分支来推进的，这块也包括大家默认就会以master分支做为主干分支，如有什么PR也是往这边来推来合并的，这样也激发大家的活跃度（从最初的没模板，到逐渐有模板，有规则）。对于活跃度，这部分也包括限制越少对新手的门槛就越低。当然github墙的问题本身也减少了一部分活跃度。

因为活跃度的问题，所以为什么master分支是开发分支，就是这个原因。

保持稳定性

在整体演进过程中无疑稳定性非常关键，在RT-Thread这边主要依赖ci机器人来辅助，所以从cla，到ci编译，到ci的一些代码检查，到ci上qemu方式的ct。都是这样。所以RT-Thread的方式核心点是依赖于机器人，然后再+人工代码review，再到发版前人工的真机测试验证。基本上都是这样的逻辑。

当然这个过程出现过rt-thread studio的问题。studio的核心问题是开辟了多仓库的战场，导致版本不同步，需要手工同步更新。

再到最近出现的milk-v duo版本不稳定的问题，核心点其实是ci的问题，一个是milk-v duo是否加入了ci build，另外一点是smart在qemu ct上涉及程度还不高。<如果说milk-v duo都没加入到ci build中，然后吐槽master没维护好导致编译都不行，这个我觉得就不要说太多的，还是先加ci build吧>

小步快跑

这个方式非常赞成。早之前做过真机stm32l4上的ct（连接到一台服务器，随着ci hook，完全无人化自动测试），但因为每次PR都做，最终导致板卡flash写坏，不能做到ct而最终撤掉。这部分可以考虑按每周或每两周、每月等的方式做一次的方式，从而达到自动release小版本的方式，这个是可以来考虑的。

针对这类的，建议可以有个专门的SIG来推进真机的自动化CT。

[unicornx]

这个方式 ......
@BernardXiong 熊大说的 ”这个方式“ 是指什么方式？是指 @supperthomas 说的 gitflow？

[BernardXiong]

这个方式 ......
@BernardXiong 熊大说的 ”这个方式“ 是指什么方式？是指 @supperthomas 说的 gitflow？

小步快跑的方式。不是gitflow的方式。至于说gitflow，或许是企业中挺好的一种方式，但适合自己的才是最好的。

[supperthomas]

Describe problem solved by the proposed feature

RTT 仓库的 master 分支的稳定性问题我感觉是老问题了，能不能从软件工程角度解决一下？否则现在发现经常 sync 后 master 就build 不过，大量的时间花费在解决 bugfix 上，但这些是可以可以通过流程控制解决的呀。 我能想到的一些改进建议, 权当抛砖引玉，希望大家各抒己见，否则社区版本如果还是继续目前这个状态，至少我个人觉得会劝退不少想来做贡献的新人

Describe your preferred solution

• 建议措施（1）改进 CI，完善自动化测试用例集合
  确保 qemu 上可以跑的几款 bsp 能够得到有效看护。这样至少可以保证部分内核的 common 功能（譬如posix 系统调用）和 qemu 上的 bsp（驱动）可以在 master 上始终确保相对稳定。
• 建议措施 （2）增加小版本周期
  完善自动化测试用例，不涉及大量人工介入方式下覆盖有限几款重点看护的真机稳定性，这样至少可以保证部分内核的 common 功能（譬如posix 系统调用）和这些真机的 bsp（驱动）可以在 master 上始终确保稳定。如果自动化测试的周期足够短的话（假设一天？），我们可以每个周期（一周或者两周）预留一天暂停 master 合入，跑完测试后就打 tag，而且我觉得为了不 block master，即使有问题也打 tag，只是在对应 tag 上给出一个问题报告的说明并提出相应的 isseu进行跟踪。另外，重点看护的真机列表可以随时间进化。
  后来觉得，如果我们不想 block master 的合入，其实可以更激进一点，就是先打 tag，然后跑测试，如果没问题就标记整个 tag 稳定，如果有问题，就把 issue 提出来，tag 一样打上，只不过我们就知道这个 tag 是不稳定的。后面任何时候拿 master 使用发现出问题都可以回溯到最近的一个稳定的版本去继续开发。当然如果发现最近几次 tag 测试都有问题，那么负责 merge 的人也可以把控一下 merg的 节奏了。
• 建议措施（3）完善大版本周期
  一个月或者两个月，但不要再长了，投入较大人力做回归测试，覆盖更多的 bsp。其实这个已经不是我关注的重点了。

我提出以上的改进建议的目标：

• 尽量不改变现有流程的基础上（master 即开发分支），也尽量不 block master 的进展（顶多每个 tag 锁死一天不许 merge）。
• 通过（1）和 （2）改善 master 的稳定性。
• 虽然我们不能百分百保证 master 上的所有 bsp 都100%稳定，但是通过（2） 中提供的tag机制，我们可以在遇到 master 不稳定时，可以回退到最近的一个相对稳定的 tag 上继续我们的开发，而不会完全 block 住而且也不清楚 master 上的哪个 commit 才是可用的。

Describe possible alternatives

No response

这个具体哪个BSP，哪个配置出现问题？可以明确一下。

[unicornx]

这个具体哪个BSP，哪个配置出现问题？可以明确一下。

我这里主要是在测试 duo（bsp/cvitek）, 也测试过 qemu-virt64-riscv 和 raspi。

但我理解：我的诉求是个通用的问题，即：如果当我们用 master 测试失败的时候，我该怎么办？目前的 git 中没有什么信息能让我快速回退到 master 上最近的一个相对稳定的 commit 去继续我的开发。最新的 tag 5.1.0 已经是今年 4 月份的了。我的改进建议就是针对这个问题的。

而且上次社区会议针对我的这个问题也说了，ci 看护目前只能解决编译问题，但解决不了运行期错误检查。具体请看 https://docs.qq.com/doc/DSG1qaFl0Qk1VSk1F

[supperthomas]

bsp/cvitek

我建议先加ci build。ci build虽然只是解决编译问题，但是暂时目前bsp/cvitek 连ci 都没加的。

[BernardXiong]

这个具体哪个BSP，哪个配置出现问题？可以明确一下。

我这里主要是在测试 duo（bsp/cvitek）, 也测试过 qemu-virt64-riscv 和 raspi。

但我理解：我的诉求是个通用的问题，即：如果当我们用 master 测试失败的时候，我该怎么办？目前的 git 中没有什么信息能让我快速回退到 master 上最近的一个相对稳定的 commit 去继续我的开发。最新的 tag 5.1.0 已经是今年 4 月份的了。我的改进建议就是针对这个问题的。

而且上次社区会议针对我的这个问题也说了，ci 看护目前只能解决编译问题，但解决不了运行期错误检查。具体请看 https://docs.qq.com/doc/DSG1qaFl0Qk1VSk1F

针对属于ci build看护的bsp，应该基本上编译总是能够通过，或者有中间某个commit不行，也在附近几个commit后就编译通过了（因为这会导致ci失败，会拦截掉后续PR的合入）。当然这个只是针对ci build，不针对执行，执行时一些测试用例都能过。所以同意以小步快跑的方式，定期出版本，这些版本可以测试得更严苛些，甚至可以做到一些重点真机也能测试通过。

[unicornx]

新建一个子任务
#9775

目前首要任务是将基于 QEMU 的自动化完善，这样保证 措施（1) 的目标达到。

[unicornx]

bsp/cvitek 还没有加到CI里 https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/bsp_buildings.yml

请问这个加 cvitek 的看护是我们自己提 pr 还是有人会帮忙加?