内容
可操作的分区器概览屏幕
直到现在，分区器着陆页对于了解系统中的设备概况以及通过双击设备页面直接跳转到该页面很有用。但是，你知道吗？从 yast-storage-ng 4.2.74 开始，你可以像在更具体的页面上一样，通过设备列表下添加的上下文操作直接使用设备，这意味着，例如，无需跳转到硬盘才能添加新分区或调整现有分区的大小。尽情享受 
更多详情：PR 1024
表格中的数字排序
我们改进了 YaST 的 UI 库 libyui 中的表格排序。到目前为止，列是根据显示的文本直接排序的，例如设备名称或专家分区器中的大小。对于某些用例，这导致了意外的排序，例如磁盘的分区按“/dev/sda1”、“/dev/sda10”、“/dev/sda2”排序，大小按“1 GiB”、“2 TiB”和“4 GiB”排序。
现在可以 为每个表格条目提供排序键，然后使用它代替显示的文本。这允许预期的排序，并且已经实现了专家分区器中的表格，如下面的两张图片所示。
改进 NFS 模块
YaST 提供了一个专门的模块来配置您的 NFS 共享。与每个 YaST 模块类似，您可以通过在终端中执行 yast2 nfs 运行它，或者从 YaST 控制中心启动它。但是，还有另一种使用 YaST NFS 模块的便捷方法：打开专家分区器！
专家分区器在左侧菜单树中提供一个 NFS 部分，您可以在其中执行 NFS 模块提供的所有操作。因此，您可以在格式化分区的同时配置 NFS 共享！
但是，在我们将 YaST 迁移到新的存储堆栈（又名 storage-ng）之后，这种集成需要一些改进。此外，在使用 NFS 模块挂载和卸载共享时检测到一些错误，请参阅例如 bsc#1006815 和 bsc#1151426。
所有这些错误都已修复，NFS 模块在独立模式和专家分区器内部运行时均按预期工作。请注意，现在现有共享的当前状态已保留。也就是说，未挂载的共享在编辑后将继续未挂载。未挂载的条目在共享列表中用星号表示，类似于专家分区器对其他未挂载设备的处理方式。所有这些改进将适用于 SUSE Linux Enterprise SP1、openSUSE Leap 15.1 和 openSUSE Tumbleweed。
安装进度改进
我们收到了一些关于安装进度报告如何工作的错误报告，同时我们也在接触它时，对代码添加了一些小的改进。
第一个变化是，现在从多个光盘安装几乎从未发生过，但仍然有一个“介质 1”列，这没有太大意义。所以我们删除了该列，如果有多个介质源，它将在需要时附加到名称中。
第二个可见的变化是在 RPM 安装的初始阶段，直到可以估计剩余时间，期间出现了一个新的 Unicode 字符 ⌛（沙漏）。
第三个变化是，现在最大时间始终限制为 2 小时，因此即使有多个源并且其中一些源花费的时间超过两个小时，它也始终显示“>2:00:00”，并且总时间也受到限制，因此它不再显示类似“>6:00:00”的内容。
第四个变化是，现在您可以无干扰地阅读 发行说明。 以前，每个软件包完成安装后，您将被切换到软件包日志选项卡。现在，只有在返回发行说明屏幕时才会重新绘制。
第五个变化是修复了显示 剩余软件包 的问题，它仅显示活动源的软件包，而不是所有软件包。因此，现在它显示所有存储库的剩余软件包。
最后，我们进行了一堆重构、代码质量改进，并添加了自动单元测试，以减少未来的回归。
Tumbleweed 前后
SLE 前后
以及新的 ncurses
末日准备：撤回的软件包
如果为我们的任何受支持的产品发布了维护更新，则可能会发生在其发布后，我们意识到它引入了新的问题，因此我们必须取消发布（撤回）它。
到目前为止，我们的维护团队始终能够找到其他解决方案，但迟早会发生需要花费太长时间才能意识到更新已损坏的情况，因此用户会安装它。
为此，我们为补丁和软件包引入了一种新的状态撤回。我们希望永远不需要它，但如果需要，我们需要它尽快——直到发布这些软件包的更好、修复的版本为止。
我们为软件包选择添加了新的过滤器“撤回的软件包”和“撤回的已安装软件包”，受影响的版本以红色突出显示，并在“版本”选项卡中带有 [已撤回] 标记
这些列表应始终为空。 此外，撤回的版本绝不会自动安装。 如果撤回了软件包版本，但已安装，则启动软件包选择时将自动打开“撤回的已安装软件包”视图，以提醒您。 然后您可以选择手动降级到以前的版本或等待可用修复版本。
总的来说，不用担心：我们到目前为止从未需要过它，并且希望永远不需要它。 尽管如此，我们还是为最坏的情况做好预防措施。
更多详情：PR 82
Qt 软件包选择速度更快
这源于前一个项目的一个副产品：在为撤回的软件包处理新的筛选器视图时，我们发现当从“所有软件包”视图切换时，可能需要很长时间（10-20 秒），因此我们开始深入挖掘以找出原因。
我们认为清除该对话框右侧的软件包列表速度很慢很奇怪；比用所有软件包填充它慢得多。经过一些调查，我们发现，在所有这些 Qt 版本（自 2006 年年中 Qt 3.x 以来）的所有更改过程中，一些内部维护工作对于这些列表项来说现在是不必要的，因为较新的 Qt 版本承担了越来越多的责任，而我们自己的维护工作现在会妨碍它并大大减慢速度。
一旦我们找到了原因，修复就很容易了：我们删除了自己的维护代码，现在依赖于 Qt 部件所做的事情，瞧，清除该列表现在会立即发生，而不是花费 10-20 秒。
更多详情：PR 82（“其他修复”）