在这些周里，我们主要在两个不同的领域工作。一方面，我们改进了 YaST 服务管理能力，增加了对按需服务的支持，并略微改善了用户体验。另一方面，我们仍在致力于新的存储层，扩展它以支持 Xen 虚拟分区，并修复 BIOS MD 设备处理等问题。
最后但并非最不重要的一点，我们的错误修复小队（你还记得 小队 吗？）修复了我们整个堆栈中的相当多的错误。
所以让我们回顾一下这些 Sprint 的亮点。
服务管理得到改进
团队投入了大量时间来改进服务管理领域。过去，YaST 适应了与 Systemd 很好地配合（Systemd 替代了旧的基于运行级别的 init 系统）。然而，还有很多改进空间，因为 Systemd 在服务管理方面增加了一些新功能，而 YaST 根本不支持这些功能。
为了探索这些变化，让我们先看看新的服务管理器用户界面。
乍一看，你可能注意到了一些变化：启动模式菜单按钮取代了原来的启用/禁用；添加了新的应用或显示日志按钮；启动/停止按钮被启动（或停止）按钮取代… 好的，让我们逐一描述这些变化。
也许最重要的更新是对 socket 激活服务的支持。但是你可能会问什么是“socket 激活服务”，对吧？简而言之，这些服务是按需启动的。例如，打印服务只有在你想要使用打印机时才会启动。而这就是启动模式按钮的意义所在。例如，你可能希望打印服务仅在需要时启动（按需），YaST 将负责设置 Systemd 单元以实现这一点。
另一个有趣的功能是浏览服务日志。请注意，只有安装了 yast2-journal，此按钮才可用，因为它使用此软件包提供的浏览器。
浏览日志将我们带到新的应用按钮。有时，启动服务并检查日志以查找潜在问题可能很有用。过去，更改在按下确定按钮时应用，但不幸的是，服务管理器随后关闭了。现在，使用应用按钮，你可以要求 YaST 真正应用这些更改，而无需关闭服务管理器（并检查日志或继续调整服务）。
但这还不是全部！在其他小变化（例如修复 bug #1080738）之外，我们仍在改进此服务管理器的用户体验。
让 Xen 虚拟分区再次伟大
重写一个存在 20 年的 YaST 部分是一个永无止境的惊喜源泉。当我们认为 Storage-ng 已经支持了旧存储堆栈处理的所有存储技术时，我们只是发现我们留下了一些东西。
在设置 Xen 虚拟化环境时，可以定义在 Xen 客户机中看到和命名的块设备，这些设备实际上是磁盘（或者几乎是磁盘，因为它们不能被常规方法分区）。换句话说，Xen 客户机可以看到一些名为例如 /dev/xvda1 和 /dev/xvda2 的块设备，而没有相应的 /dev/xvda。
从 YaST 的角度来看，你可以对分区执行任何可以执行的操作（格式化、挂载等），除了你无法删除它们或创建更多（因为它们不是由磁盘支持的，从 Xen 客户机的角度来看）。我们称这些设备为“Xen 虚拟分区”。旧的存储堆栈假装这些设备只是一个虚构的 /dev/xda 磁盘的普通分区，该磁盘在系统中不存在，但仍然出现在分区程序和 AutoYaST 配置文件中。新的堆栈根本不支持 Xen 虚拟分区。
我们在上个 Sprint 中修复了这个问题，这使得该功能在 SLE-15 安装过程中可用，这要归功于安装程序自更新功能。因此，无论你的 Xen 客户机运行的是完全更新的 SLE-15、Leap 15.0 或 Tumbleweed 版本，还是使用访问安装程序自更新存储库安装 SLE-15，虚拟分区都可见于分区程序的硬盘部分。
它的工作方式类似于旧的（预 Storage-NG）分区程序，但没有用于将虚拟分区分组的人工磁盘。请参阅以下屏幕截图，其中 xvda 是 DVD，xvdb 是真实磁盘，xvdc1 是 XEN 虚拟分区（没有 YaST 添加的虚假 xvdc）。
只有编辑按钮才能按预期工作，允许用户挂载和/或格式化虚拟分区。其他按钮只是显示不同不支持操作的相应错误。
我希望在我的 Leap 15.0 安装程序中
作为 Xen 分区主题的补充，值得一提的是安装程序的自更新功能始终适用于所有基于 YaST 的发行版。但是，与 SLE 不同，openSUSE 不提供官方的自更新存储库，这意味着该功能默认情况下在 openSUSE Leap 中被禁用。这是否意味着如果你想在 Xen 虚拟分区之上安装 Leap，你必须等待 Leap 15.1 或切换到 Tumbleweed？不完全是。
如果你真的想在 openSUSE Leap 15.0 安装过程中使用最新的 YaST 功能，有几种方法可以实现它。例如，使用 Leap 15.0 Live 镜像进行安装（或升级）。Live 镜像会定期刷新，因此它们可能包含比 Leap 15.0 正常 ISO 中安装程序更新的安装程序。还有使用自更新功能与非官方（和不受支持）存储库的方法。有关所有选项的摘要，请查看 Bugzilla 上的此评论。SLE 用户不需要任何这些技巧，因为有一个官方存储库用于安装程序自更新机制，确保 SLE15 始终可以使用所有关键软件包的更新版本进行安装。
一个新的小部件来管理服务
你认为服务管理仅限于服务管理器吗？当然不是。 
如你所知，有几个 YaST 模块允许我们的用户设置几个服务，如 DNS、DHCP、Samba 等。所有这些模块都提供了一种配置如何以及何时启动这些服务的方法。
因此，作为改进服务管理体验的一部分，我们推出了一个 新的小部件，它提供了一些好处
- 允许将服务设置为按需启动。
- 提供跨所有模块一致且统一的界面。
- 能够处理涉及多个服务的情况（例如
yast2-samba-server或yast2-iscsi-client）。
顺便说一下，我们已经调整了所有这些模块以使用新的闪亮小部件。
更好地处理 libyui 中的大文件系统
我们在 上个 Sprint 中修复了大于 8EiB 的磁盘的问题。但是，该修复旨在用于 SLE12 和 SLE15 维护更新，因此我们无法进行重大更改，并且仅修复了最重要的部分。
对于 SLE15-SP1/Leap 15.1 和 openSUSE Tumbleweed，我们可以进行更多更改，因此我们进行了一些不兼容的改进。
最初，大小是使用 long long 数据类型实现的，这是一个 64 位有符号整数（最大值为 8EiB）。我们切换到 Boost multiprecision C++ 库，该库实现了任意精度整数。它的工作方式类似于 Ruby 中的 Integer 类，它在需要时向数据添加更多位。
当然，它仍然取决于底层 libzypp 库中的限制，该库使用 64 位有符号整数，但单位为 1KiB，因此限制应为 8ZiB。通过此更改，我们甚至可以为更多做好准备。
此外，我们添加了更多单位来转换为字符串表示形式。最初它使用 TiB 单位，这导致数字过大，现在 EiB 大小将使用 EiB 单位按预期显示。
此外，我们添加了编写单元测试、评估代码覆盖率并将其报告给 coveralls.io 的支持。有了这个支持，我们能够编写 libyui 中的第一个单元测试！代码覆盖率现在为令人尴尬的 2%，但我们才刚刚开始！
Rubocop 检查加速
在 之前的博文中，我们报告说我们改进了在 yast2-storage-ng 包中运行单元测试的速度。加速基于并行执行并使用所有处理器。这次我们改进了 Rubocop 检查。
通常，Rubocop 会扫描目录中的文件以进行检查，然后按顺序处理找到的文件。如果需要检查的文件有数百个，这可能需要很长时间。
与之前的加速类似，我们利用可用的处理器并并行运行多个 Rubocop 实例。实现稍微复杂一些，因为 Rubocop 本身不支持并行扫描。但是，可以评估检查的文件，根据处理器的数量将它们分成组，并为每个组并行启动一个单独的 Rubocop 实例。
如果你对细节感兴趣或想在你的项目中也使用并行 Rubocop，请查看 yast-rake Ruby gem 中的 实现。
当然，这项改进对 yast2-storage-ng 包产生了重要影响，Rubocop 需要检查 600 多个文件。以下是数字
- 在本地运行 Rubocop（启用超线程）
- 在较旧的四核 CPU 上快 3.6 倍（从 44 秒到 12 秒）
- 在新八核 CPU 上快 6 倍（从 35 秒到 6 秒）
- 在 Travis 上：快 1.5 倍（从 69 秒到 47 秒），这是可能的最大值，因为 Travis 大约有 1.5 倍的 CPU 构建能力
如你所见，对于大型项目，在本地系统上的加速非常好，即使在 Travis 上也很不错。
接下来是什么？
Sprint 61 已经在运行中，新的存储层和服务管理是我们再次集中资源的主要领域。希望在两周左右的时间里，我们会发布我们这次的成就。
敬请期待！