openSUSE:构建服务概念信任

跳转到：导航，搜索
开放构建服务
最终用户 - 打包者 - 开发 - 安装 - 协作 - 比较

本文档状态

本文档描述了将一些指标集成到 openSUSE 构建服务 中的初步概念。它基于 Adrian 的头脑风暴（在旧英文 wiki 中）以及受到 SUSE 的同事和开源社区内的同事许多良好讨论的启发。请注意，此概念仅提出可能实施的指标。基于反馈，这些指标将在未来几周内确定。

所有想法和建议都强烈关注 openSUSE 构建服务，但它们也应可用于 openSUSE 的其他基础设施部分。本文档不描述 信任实施。

尽管 的论文将侧重于拟议的信任指标，但本文档提出了进一步的特征（质量和维护），这些特征是在 Marko 在 SUSE 进行的访谈中提出的。

欢迎反馈！

项目目标

openSUSE 构建服务 为每个人提供了以相对较小的努力为许多 Linux 发行版构建软件包的机会。因此，每个软件包可用的版本和变体数量相对较高。因此，我们需要一种强大但简单的工具来评估这些软件包，这些软件包立即可在 openSUSE 软件门户 上使用。

本文档提出了一些前景，可以获得许多不同的值，这些值可以分为三个主要类别

  • 信任
  • 评级和接受度
  • 质量和维护

对于每个类别，我们可以基于单个加权值的总和计算累积值，这些值可以向用户表示。还可以计算更通用的最终分数。作为对此的可能扩展，经过身份验证的用户应该能够根据现有的指标配置个人分数，以满足其个人需求。

整个项目主要基于信息检索、数据挖掘和统计，但也包括来自其他研究领域的不同方面。

我们希望尽可能多地评估软件。因此，参与此评级对于 openSUSE 构建服务社区来说至关重要。由于像开源社区这样多样化的人群很可能不同意所有已实施的指标，因此每个用户都可以禁用整个系统，并可以明确禁止计算每个可能的值。

尽管所有提出的值都致力于评估软件包而不是其生产者，但本项目确实进行大量数据挖掘。因此，必须评估是否存在任何侵犯隐私的行为。此外，一旦为帐户设置了员工标志，就应默认禁用所有将能够测量 Novell 员工绩效的指标。

可能的指标简要总结

信任

信任是一种依赖关系。受信任的方被假定为寻求履行政策、道德规范、法律及其以前的承诺。[1]

由于信任具有高度的个体性质且极其主观，因此很难为我们想要衡量的过程推导出广泛接受的全局信任级别。因此，我们需要一种常用的方法来描述个人在 openSUSE 构建服务中的行为。

请注意，以下所有指标都不能保证即使不惜一切代价的人也能获得高评级。

信任评级标准

每个人都有自己定义可信与不可信的标准。在软件打包方面，在与 SUSE 的许多同事讨论中，有三个主要因素是

  • 谨慎
  • 可靠性
  • 响应性

由于这些因素以及进一步因素之间的权重在很大程度上取决于个人偏好，openSUSE 构建服务应允许用户根据自己的个人需求配置每个可用值的相关性。

指标

  • 行为准则
    用户接受遵循一些指导原则的二进制值。
  • 已验证的身份
    用户已向 openSUSE 项目识别自己。
  • 基于行动的评级
    用户请求的评级（想象一种类似于知名在线拍卖和购物网站的反馈机制）。
  • 信任网络
    每个用户可以为其他用户和项目分配信任级别。
  • 可靠关系
    • 隶属关系
      一个人可能通过受雇于 Novell 或成为 Novell 的业务合作伙伴等方式与 openSUSE 建立一个或多个隶属关系。另一个例子是 openSUSE 会员资格。
    • 上游隶属关系
      一个人可能与上游开发有关系，例如作为开发人员、维护者或打包者。
  • 评论
    每个软件包都可以在多个标准上进行评论。
    • Specfile 由 openSUSE 维护者审查
    • 代码和补丁由 openSUSE 维护者审查
    • 代码和补丁由 openSUSE 安全团队审查
  • 官方制造商标签
    将软件标记为由其制造商提供，以使用户能够仅使用官方存储库。

评级和接受度

这可能是最重要的类别，因为它最具互动性，并且软件门户的每个用户都可以为此做出贡献。

指标

  • 受欢迎程度/接受度
    • 软件包下载量
    • Repo-Metadata 下载量
      （这两个值应作为总数、按时间段、按版本或按发布版提供。）
  • 用户评级

质量和维护

指标

  • rpmlint 和 lintian/linda
    从 rpmlint 或 lintian/linda 结果中提取一些质量指标
  • 软件包历史记录/版本号
    检查软件包更新频率与上游更新。
  • 在多种架构和产品上的可用性
    保留所有架构和产品上所有构建的历史记录。
  • 变更日志
    解析 Changelog 以获取交叉引用并从中提取一些基本信息，例如引用的错误跟踪器。
  • 活动/活力
  • 依赖项和反向构建依赖项

不可用指标

  • 错误统计信息
    • # 开放错误
    • # 阻止错误
    • # 严重错误
    • # 主要错误


详细指标描述

信任

衡量信任的方法

行为准则

如果用户签署行为准则（一些 openSUSE 和 openSUSE 构建服务的指导原则），则他声明他认真对待自己的工作，他的贡献的主要目标是为整个社区带来利益。

虽然这是一个二进制值，但它表明了某人是否同意尊重基本规则。

已验证的身份

通过以受信任的方式识别自己，例如发送工作/居住地址、联系方式或身份证复印件，向受信任的实体识别自己，可以使自己对自己的工作负责得多。SUSE/Novell 员工通过签署其工作合同完成了此身份验证，但其他人应该能够通过将他们的 ID 发送给审查委员会或适当的标准流程来达到相同的水平。

有几种选择。例如，我们可以采用 CAcert.org 的保证流程，其中新用户必须获得现有用户的批准才能创建证书。另一种可能性是要求用户提交其公共 GNU 隐私卫士 密钥，该密钥必须由给定数量的知名 openSUSE 构建服务用户签名。

基于行动的评级

动机：在一个或多个项目中表现出色的知名人士比迈出打包第一步的新手更值得信赖。

凭借其开放的设计，openSUSE 构建服务鼓励其用户协作和分享他们的知识。协作过程映射到所谓的 提交请求，正确地意味着用户请求将更改从一个软件包添加到另一个软件包 - 通常是从另一个项目。请求的接收者评估提交的修改，然后选择接受或拒绝请求。

我们希望为提交请求（和 预期请求）添加评级，以便每个用户都可以在一个简单的量表（优秀 - 较差）上对所有以前处理的请求进行评级。这些评级存储在包含一些附加信息（例如，发送者、源项目、源软件包、接收者、目标项目、目标软件包）的中央数据库中，以便可以根据足够的样本量推导出两个评级，一个相对于给定项目，另一个是总体分数。

这些评分例如可以通过 openSUSE 构建服务客户端在每次请求时显示，或者我们可以为每个项目计算每个人的评分。

信任网络

根据选择的用户识别实现方式，此值也可能显示用户在 openSUSE 构建服务社区中的知名度。因此，非二元值将使这一事实更有意义。可选地，我们可以将其拆分为一个布尔值：用户是否通过标准化流程证明了他的身份，以及用户之间是否可以添加评级链接的某种社交网络？这些评分具有很强的主观性，但我们应该使用一个众所周知的方案，例如 GNU 隐私卫士的等级 '未知'、'无'、'边缘' 和 '完全'。

作为 GNU 隐私卫士方法的替代方案，应该考虑 Advogato 信任指标。它基于一个 容量约束流网络 [2]，因此应该更能抵抗大规模攻击。它不难理解，并且计算速度相当快。

可靠的关系：隶属关系状态

如果一组人（这可以是一个开源项目或一家公司）签订合同，承诺对报告做出响应并处理存储库中定义的时限内的即将出现的问题，他们就证明了维护其软件包的意图。因此，在合同期限内必须保证给定的劳动力。如果个人离开该小组，剩余的小组必须提名替代者，或者在团队恢复完整之前暂停合同。应该有几个级别，主要取决于响应时间和团队规模。盟友公司的员工应符合这种关系方案。

Novell 员工具有更可靠的关系。

这种关系应该有大约三到五个级别

  • Novell 员工
  • Novell 承包商
  • openSUSE 成员
  • 无关系

可靠的关系：上游隶属关系

与上游有密切联系的人或团队可能比与项目没有任何关系的人更热衷于维护他们的软件包。这可能也适用于软件包的质量。

由于用户可能是多个 openSUSE 构建服务项目的维护者，因此应该提供每个项目的信息，说明他是否与上游项目有关系，例如：

  • 开发者
  • 维护者
  • 打包者
  • 无关系

官方制造商标签

有些用户只想安装制造商提供的软件。因此，我们应该为每个项目添加制造商标签，这些标签由一群官僚维护。用户可以选择所有可用的标签，从而选择他希望在系统上安装哪些供应商的软件。

初始方法可以通过为制造商分配一组签名密钥或类似方法来实现。

用户评分与接受度

这可能是信任之下最重要的类别，因为它最具互动性，并且软件门户的每个用户都可以为此做出贡献。

获取用户评分和进一步可用数据的方法

用户评级

类似于 Wikia 搜索，我想在软件门户中添加一些基于 AJAX 的评分和评论功能。

用户应该能够在无需登录或类似障碍的情况下为每个呈现的软件包进行评分。此评分应该代替此软件包与此搜索结果的相关性，就像 Wikia 中用户对该软件包的总体反馈一样。星级越多越好。除此之外，用户还可以将一个软件包标记为“聚光灯”标签，这意味着该软件包应该获得额外的关注。注册用户可以使用短单行评论，这些评论可以在之后删除。他们可以为其他用户添加一些有用的提示或警告。

一些管理按钮，例如报告错误或提醒安全团队，应该完成交互式搜索结果。

流行度/接受度（下载统计）

“适者生存” 也适用于软件包和存储库，这意味着用户只选择那些不会破坏其系统并为他们带来巨大好处的存储库。

downloads.opensuse.org 重定向机制是衡量存储库或软件包流行度的宝贵来源。我们应该计算软件包下载量（每个软件包和存储库）和元数据下载量（每个存储库）的时间相关统计数据。

质量与维护

如果没有软件包和错误之间的强关联，就很难获得软件包的质量和安全指标。因此，我强烈建议集成一种将错误分配给软件包的可能性，就像其他主要发行版一样 [3] [4] [5] 在 Novell 的 Bugzilla 中。另一方面，构建服务团队应该考虑创建自己的错误跟踪器，因为可能不希望 openSUSE 构建服务的所有软件包的所有错误都位于 Novell 的错误跟踪系统中。首选方法可能是为每个构建服务项目创建一个单独的错误跟踪系统。

然而，可以通过自动化测试等方式推导出一些软件包质量指标。

测量质量的方法

rpmlint & lintian/linda

存在自动化工具来检查软件包是否存在常见错误和策略违规行为。因此，没有这些自动化检查报告的任何错误的软件包很可能比有多个投诉的软件包具有更高的质量。

rpmlint 是一个用于检查 rpm 软件包中常见错误的工具。默认 rpmlint 软件包中包含以下检查：

  • 标签检查 (TagsCheck)：检查是否存在一些 rpm 标签。
  • 特定于发行版的检查 (DistributionCheck)：检查二进制 rpm 软件包中的发行版特定信息。
  • 二进制检查 (BinaryCheck)：检查二进制 rpm 软件包中的二进制文件。
  • 配置文件检查 (ConfigCheck)：检查是否所有配置文件都已到位。
  • 位置、权限、组和所有者检查 (FileCheck)：测试文件的各个方面：位置、所有者、组、权限、setuid、setguids 等。
  • 签名检查 (SignatureCheck)：检查是否存在 PGP 签名。
  • FHS 检查 (FHSCheck)：检查 FHS 合规性。
  • 特定于源的检查 (SourceCheck)：验证源软件包的正确性。
  • i18n 检查 (I18NCheck)：测试 i18n 错误。
  • 菜单系统检查 (MenuCheck)：测试菜单系统。
  • %post; %pre, %postun 和 %preun 脚本检查 (PostCheck)：再次检查 post/pre 脚本。
  • /etc/rc.d/init.d 检查 (InitScriptCheck)：检查 init 脚本。
  • Spec 文件检查 (SpecCheck)：针对源 rpm 的 spec 文件进行各种测试。
  • Zip/Jar 文件检查 (ZipCheck)：验证 Zip/Jar 文件的正确性。
  • Pam 配置文件检查 (PamCheck)：检查 PAM 配置是否正确。
  • Rpm 文件检查 (RpmFileCheck)：检查文件名长度（!>64）。
  • 品牌检查 (BrandingPolicyCheck)：验证与品牌相关的事务是否符合要求。
  • 桌面翻译检查 (DesktopTranslationCheck)：搜索未翻译的桌面文件。
  • 文档文件依赖性检查 (DocFilesCheck)：%doc 文件不得引入新的依赖项。
  • 重复检查 (DuplicatesCheck)：检查单独打包的重复文件。
  • KMP 策略检查 (KMPPolicyCheck)：验证 kmps 是否具有正确的依赖项。
  • 库策略检查 (LibraryPolicyCheck)：验证共享库软件包是否符合相应的打包策略。
  • LSB 检查 (LSBCheck)：检查 LSB 合规性。
  • 命名策略检查 (NamingPolicyCheck)：验证几个软件包（例如 python、perl、php、ruby、apache）的正确命名。

首次实现应该只检查是否任何测试失败，并可能检查发现的问题数量。作为后续改进，我建议添加一个解析器来识别失败的测试，并进一步为识别的问题添加严重程度量度。

相应的 Debian 工具是 lintian 和 linda。它们针对 Debian 策略手册 执行各种检查，因此它们应该集成到构建服务的 Debian 打包过程中。（请参阅 FATE 请求 #304951。）

可能的进一步数据来源

  • 元数据
  • 变更日志
  • 来自测试submitpac

测量维护的方法

软件包历史记录/版本号

有些用户对最新的软件有很高的需求。另一方面，许多用户只想获得（安全）错误修复，而无需进行任何进一步的更改或功能添加。

为了推导出这些需求的指标以及估计软件包维护的活跃程度，我们应该保留所有软件版本历史记录，包括一些关键日期（首次上传、首次成功构建、首次通过所有自动化测试的构建）。结合指向上游存储库的新版本（例如 CVS、SVN、Git、http/ftp 下载 URL）的链接，我们可以推导出一些有趣的指标

  • 两个上游更新之间的时间 t
    Δ (t上游版本 i; t上游版本 i-1)
  • 两个软件包上传/签入之间的时间 t
    Δ (t上传版本 i; t上传 i-1)
  • 两个软件包构建之间的时间 t（带有检查失败）
    Δ (t构建版本 i; t构建 i-1)
  • 两个完美软件包构建之间的时间 t
    Δ (t完美版本 i; t完美 i-1)

结合有意义的加权函数，我们可以推导出长期统计数据，包括这些时间参数的方差和期望值。

除此之外，我们可以将这些值相互比较，以获得更重要的值

  • 上游更新与相应软件包上传之间的时间 t
    Δ (t上游版本 i; t上传版本 i)
  • 上游更新与相应软件包构建之间的时间 t（带有检查失败）
    Δ (t上游版本 i; t构建版本 i)
  • 上游更新与相应的完美软件包构建之间的时间 t
    Δ (t上游版本 i; t完美版本 i)

软件包损坏的时间长度可能也对用户感兴趣

  • 软件包损坏与成功或完美构建之间的时间 t
    min{Δ (t损坏 i; t构建 j); Δ (t损坏 i; t完美 j)} 其中 j=>i。

由于分布式开发过程的性质，只要有以前的工作版本可用，软件包可能会损坏一段时间。必须区分由构建依赖项引起的构建问题和由软件包本身引起的构建问题。

作为未来的改进，我们还可以考虑遗漏的软件包版本，并添加考虑上游版本主要/次号的权重。

在多种架构和产品上的可用性

一个好的打包者会为所有已发布的架构（如 i586、amd64、s390、ppc）以及旧的（未停用的）产品（例如 openSUSE 10.2、openSUSE 10.3）照顾他的软件包。除了上述版本和构建历史记录之外，我们应该增强版本和构建历史记录，以观察所有平台和产品。

从软件包的变更日志中推导指标

在其他方面，SUSE 软件包约定 定义了一些基本规则 如何引用主要的错误跟踪器，如 Novell Bugzilla、GCC、Gnome 或 KDE 在软件包的变更日志中。它们的语法主要由一个错误跟踪器的标记组成，后跟井号和括号中的错误编号，例如：(GCC#4711), (bgo#0815)或(KDE#2342)

此外，还有一个定义格式用于引用 CVE© 标识符。CVE© 是一个公开可用且免费使用的列表或常见计算机漏洞和暴露的标准化标识符字典。包含 CVE 标识符的变更日志条目很可能包含安全修复程序或至少处理给定的威胁。

类似于上述上游和软件包版本历史记录的指标，我们可以解析变更日志以获取交叉引用，并从错误跟踪器中提取一些基本信息并计算一些值

  • 每个软件包版本中修复/覆盖的错误数量
  • 每个版本的修复/覆盖错误的长期平均值
  • 每个错误报告与修复之间的平均时间
  • 每个软件包版本中错误报告与修复之间的平均时间

为了获得有意义的值，我们应该将它们与上述版本历史记录结合起来观察。我们还应该在可行的情况下计算方差和期望值。

活动指数/活力

待办事项

反向构建依赖项

一个经验法则是，如果软件包具有很少的构建依赖项，则更容易维护。构建依赖项越多，软件包可能更容易损坏，并且可能需要更多的工作。

尽管这是一个维护良好的弱指标，但这个值对构建服务的许多用户来说非常重要。例如，发布经理强烈依赖此值来决定在后期发布过程中更新哪些软件包。

可能的进一步数据来源

  • 引入新的基础存储库
    • 打包者多久添加一个新的基础存储库？
    • 他们多久能获得大量软件包成功构建？
  • 评估新软件包版本的标签（例如，可选、推荐、安全）
  • 连续性（衡量某人参与项目的时长。非常弱的指标？）

参见

从 "https://en.opensuse.net.cn/index.php?title=openSUSE:Build_Service_Concept_Trust&oldid=171190" 检索