Portal:Leap/SLEFeatureRequests:Personas
本页旨在总结正在直接请求的 SUSE Linux Enterprise (SLE) 功能请求的类型。
了解这些用户画像可能有助于我们识别当前流程中的瓶颈并加以解决。您会看到，它们也可能根据 openSUSE 的产品阶段而变化，这或多或少地反映了 SLE，通常会延迟一两周。
本文档是作为记录 Community SLE Feature requests 的努力的一部分而创建的。
用户 A - 提交针对具有 SLE 起源的软件包的提交请求
用户 A 提交了对同时在 openSUSE Leap 和 SLE 产品之一（称为 SLE 起源）中发布的应用程序的更新请求。
变更是如何请求的？
根本没有功能请求跟踪器。变更直接作为 openSUSE Leap 提交请求提交。请求者可能不知道他正在触及具有外部来源的软件包。
当前处理方式
Origin reviewers 将拒绝提交，因为它正在触及具有 SLE 起源的软件包。拒绝消息将包含指向 SLE Feature Requests 的指针，以及请求现在被跟踪为针对 SUSE Linux Enterprise 的功能请求的信息。报告者必须在变更请求被报告或计划在后续发布阶段实施的情况下，另外创建一个 ECO 请求。
早期功能请求中的复杂情况
- 当前流程拒绝原始提交请求通常是一个坏消息。如果功能被接受，代码将被重用，但是变更被接受于 OBS 的不同实例，因此我们不能简单地覆盖它。
- 另一个问题是报告功能更新。当前 SLE 功能请求对外部贡献者不可见。他们必须要求有权访问的人员提供更新，否则，该过程看起来像一个黑洞。
后期功能请求中的复杂情况
与早期功能请求相同的问题。 ECO 请求必须得到多个利益相关者的批准，这本身可能需要几天时间。我们可能会遇到请求在 RC 阶段报告时作为维护更新处理的情况。如果变更触发大规模重建或提供不向后兼容的变更，则变更可能会推迟到下一个 Service Pack 中。
如果维护更新在四月报告变更请求，而 FCS 日期在七月下旬。这可能会带来一些额外的复杂情况，请参见用户 B。
该请求通常需要有理由支持，这在 Late feature 请求的情况下尤其重要。应该清楚为什么这么晚才进行变更。在 RC 完成后仅进行更新通常是一个充分的理由。
用户 B - 提交针对两种不同来源的请求
用户 B 想要与 openSUSE Leap 分享他在 Factory 中的变更。他这样做是在业余时间。变更涉及两个软件包，一个应用程序和一个库。应用程序在 openSUSE Leap 和 Package Hub（Leap 或 Factory 起源）中发布，而库在 SLES 和 openSUSE Leap 中发布（SLE 起源）。
变更是如何请求的？
根本没有功能请求跟踪器。变更直接作为 openSUSE Leap 提交请求提交。请求者可能不知道他正在触及具有外部来源的软件包。
当前处理方式
- 库 - 与用户 A 相同的处理方式
- App - SR 处于挂起状态，并引用了针对 SUSE Linux Enterprise 的功能请求。
早期功能请求中的复杂情况
与用户 A 相同的情况，区别在于我们明确地阻止了贡献者。
他通常已经完成了工作（代码），并且我们强迫他保留一个针对 Leap 的开放提交请求，直到 SLE 变更登陆 Leap。
在早期功能请求的情况下，延迟很容易达到几天到两周（最好的情况）。请记住，代码部分已经准备好了。
后期功能请求中的复杂情况
与早期功能请求相同的问题。
在 Late feature 请求的情况下，延迟取决于它是否将被视为维护更新。如果不是维护更新，那么与早期功能请求相比，可能只需要多几天时间，这归功于当前的 ECO 处理方式，但如果它是维护更新，则可能需要几个月的时间。例如，如果请求是在春季的 Public RC 左右创建的，而发布日期在夏季（例如七月）。以维护更新的形式处理 Late feature 也会意味着在 openSUSE Leap 中也以维护更新的形式引入相关的变更。SLE 变更不会传播到 Leap，直到 SLE GA（openSUSE Leap GA 后的几周）。
如果维护更新在四月报告变更请求，而发布日期在七月下旬，那么维护者的变更将被阻止长达三个月。对于下一个版本，App 提交至少要被拒绝用于当前版本。
用户 C - 提交针对两种不同来源的请求，该软件包未在 SLES 中发布
用户 C 致力于“复杂的软件堆栈更新”，提交了针对具有 SUSE:SLE 起源但未在 SLES 中发布的软件的功能请求。在某些情况下，它在不同的“分层”产品（Storage 或 Caasp）中发布。分层产品不希望在没有充分理由的情况下更新软件包。SLE 人员不在乎，因为他们不发布它。
变更是如何请求的？
根本没有功能请求跟踪器。变更直接作为 openSUSE Leap 提交请求提交。报告者可能不知道他正在触及具有外部来源的软件包。
当前处理方式
任何具有 openSUSE 起源（Factory、Leap）的提交请求都将与用户 B 的情况相同。这意味着被相关的提交阻塞。
软件包具有 SUSE:SLE 起源的情况与用户 B 略有不同，因为该软件包未在 SLE 中发布。请参阅以下选项
- 来自 SUSE:SLE* 项目的软件包仅用作 SLES 的构建依赖项，但未发布。
- 软件包由 SLES 之上的其中一个分层产品发布。这可能是 SUSE Manager、SUSE Storage 或 SUSE Caasp。这些产品将一些软件包保留在 SUSE:SLE 结构中，以避免重复或简化维护工作。
早期功能请求中的复杂情况
- 对于仅构建依赖项的情况，没有并发症。处理方式仍然是通过 JIRA 请求（类似于用户 A），但评估部分在当前流程中被认为是过多的，并且是重新处理的候选对象。
- 如果软件包在非 SLE 产品中发布，并且很可能也是 SLE 的构建依赖项
这里的斗争在于有人如何确定软件包是否在某个产品中发布，以及在哪个产品中发布。除非明确查找，否则这并不明显。例如，通过以下 SCC query 查询，该查询仅供员工使用。
这些产品通常镜像 SUSE Linux Enterprise 计划，但流程可能略有不同。一些产品可能犹豫或难以更新此类软件包，**因此需要清楚地说明为什么需要进行更改**。
后期功能请求中的复杂情况
- 对于仅构建依赖项的情况，可以跳过 ECO，因为该软件包未作为任何产品的一部分发布。但是，快速通道流程并未正式化或正式化，因此它被视为例外情况，需要进行沟通。这可能被视为开销。
- 通常与用户 B 的 Late feature 处理方式相同。但是，在请求变更时，必须尊重相关产品的生命周期。它可以在 SUSE Linux Enterprise 之前或之后发布。团队/产品通常需要很好地理解为什么请求变更才能采用变更。
用户 D
用户 D 通过 Bugzilla 请求更新 Leap 应用程序，他不知道这是一个 SLES 软件包。他只是要求从新更新中获得特定功能，该功能尚未在 Leap 中可用。
变更是如何请求的？
变更通常通过 Bugzilla 在 openSUSE Distribution 中请求。
当前处理方式
在某些情况下，工程部门会将其简单地处理为错误并基于该错误创建更新请求。此类请求很少被交叉检查。如果 Bugzilla 条目不是请求修复特定错误，则应将其视为幕后的变更请求。
目前正在做的是，发布经理会检查所有新的传入错误，优先级设置为 P5（无）。并代表他们打开 SLE 功能请求。
与例如用户 A 的主要区别在于，变更本身并未提交，只是被请求。请求的理由更为重要。**为什么需要变更？如果未在给定版本中实施，会发生什么？** 这在 Late feature 请求的情况下尤其重要。
用户 E
我们合作伙伴公司的用户 E 在 openSUSE Leap 错误中要求更新 Leap、SLE、Factory 中的软件。因为有一个影响所有人的问题。
变更是如何请求的？
变更通常通过 Bugzilla 在所有 openSUSE Distribution 产品中请求。
当前处理方式
这与 D 相同。但是区别在于，这来自的不是 openSUSE 项目成员，合作伙伴可能有不同的工具（TAM）来传播变更。因此，这些可能可以从 4k 软件包的范围中排除。
用户 F
用户 F 是 SLE Public Beta program 测试的一部分，并直接针对 SLE 提出了功能请求。报告者可能是 openSUSE 项目的成员，也可能不是。
变更是如何请求的？
这些功能由不属于合作伙伴计划或没有专用 TAM 的人员在 SUSE Linux Enterprise 的 Public Beta 产品中的 Bugzilla 中报告。以及通过合作伙伴功能请求流程在 JIRA 中为合作伙伴或具有专用 TAM 的客户报告。
当前处理方式
Public Beta 经理会以与 openSUSE 发布经理对用户 D 相同的方式跟踪该功能。