openSUSE:DyadProposal

跳转到：导航，搜索

Dyad Proposal

简介

openSUSE 项目在其伞下拥有多个不同的项目，这些项目共同支持 openSUSE 和 SUSE 发行版的构建。其中许多项目都通过开源开发人员、openSUSE 社区成员和 SUSE 雇员的贡献来支持。本提案由 openSUSE 社区与利益相关者共同制定，旨在论证从 SUSE 处征集资源，以通过 software.opensuse.org (software.o.o) 改造和增强安全的软件供应链。Software.o.o. 是许多新用户尝试 openSUSE 发行版时留下的第一印象，并且该网站给用户留下持久的印象。作为从 Open Build Service 开发的软件包的前端，software.o.o. 是无数开源开发人员使用的应用程序商店。投入资源改造 software.o.o. 将增强 openSUSE 发行版的可用性，加速 SUSE 企业发行版的使用，并支持核心业务功能；本提案将附带一份商业案例，阐述改进的 software.o.o. 将如何帮助 SUSE 的业务，以及社区软件如何通过 PackageHub 被消费。由于该提案涉及两个类似且相关的议题，请将相关讨论称为 Dyad Proposal。software.o.o 和 PackageHub 的名称并非要被替换。Dyad Proposal 的目的是消除在讨论与本提案相关的议题时可能产生的任何混淆。

情况

重组、人员流失和多年来贡献呈下降趋势* 使 software.o.o. 处于破败的状态。software.o.o. 的责任/所有权在于 openSUSE 社区，并得到 SUSE 数据中心管理部门总监的支持，但该部门总监已离职，团队也不复存在。software.o.o. 可以从 SUSE 获得具有增强和改进网站可用性的技能的支持。software.o.o. 列出了各种不同的软件包，适用于不同的发行版，包括 openSUSE Leap、Tumbleweed、SUSE Linux Enterprise (SLE)、Fedora、CentOS、Debian 等。在 OBS 中构建的软件包显示在 software.o.o. 上，但 UI/UX、命名和发行版的可见性以及网站/应用程序商店功能方面的一些不一致性会导致新用户感到困惑和故障，并导致一些用户不愿尝试 openSUSE 的 Leap 和 Tumbleweed 发行版，这会影响新用户尝试和理解 SLE。software.o.o. 需要彻底改造和新的策略，以帮助增加 SUSE 和 openSUSE 发行版。社区的贡献正在通过 PackageHub 为 SUSE 产品带来益处。希望将软件放在 SLE 上的人明确建议从 packagehub.suse.com 获取他们的软件包。但是，考虑到 openSUSE Leap 15.3 和 SLE 15 SP3 之间的兼容性（Closing the Leap Gap），我们无法保证人们会明确使用 packagehub.suse.com，因为 software.o.o. 也列出了 SLE 软件包，例如 SLE:backports。本提案要求为该项目配备三名开发人员。已确定这些资源至少需要一名 UX/UI 人员和两名编码人员。还需要资源来记录、测试和自动部署。确定需要 1.5 个全职当量 (FTE) 来完成和维护 Dyad Proposal。需要太多的元素和专业知识，因此需要一个团队和/或来自现有团队的资源来帮助实现拟议的项目。需要一名项目经理来确保项目按计划进行。

目标

构建新的 software.o.o. 原型将通过现代化软件包和容器的消费方式，提供最终的安全软件供应链。通过社交化方法，采用评级系统、评论、相关/有用的信息，将创建一个以解决方案为导向的共享内容界面。设计和结构将补充 Open Build Service 和 PackageHub。改造 software.o.o. 将为 SUSE 决策者和网站用户提供数据。这种建设性的协同环境将有助于社区和企业利益。

Community Feedback

openSUSE 社区一直在进行每月冲刺，致力于项目中的网站，而 software.o.o. 是一个持续讨论的话题。11 月 12 日还进行了一个研讨会。研讨会记录可以在 https://etherpad.opensuse.org/p/softwareworkshop 找到，并已纳入以下反馈中。反馈显示了许多有用的功能列表，这些功能将有助于提高网站的可用性。改进包括

  • 拥有像 GitHub 一样的星级系统（或点赞/踩）来评级项目/软件包，以帮助了解哪些软件包最受欢迎/最受尊敬。（类似于 GNOME Software API）
    • 对维护者进行评级，以便用户可以看到他们可以信任谁来使用主仓库
    • 拥有一个平台，维护者和用户可以在其中进行交流并围绕软件包创建社区（点赞/踩、论坛？评论区、最下载的软件包自动化）
    • 软件包评级
      • 至关重要的是要强调评级是关于软件包而不是上游软件（沟通挑战）
  • 允许显示软件包的新鲜度日期
  • 让 software.o.o. 展示最受欢迎的结果。使用 https://#/piwik/ 的脚本可以成为解决方案。
  • 可以选择加入或退出（黑名单）在 software.o.o. 上显示主仓库，这样那些正在使用这些软件包的人，这些软件包不用于消费的人，就不会被联系到以修复它们。（OBS 可能需要一个可以被 software.o.o. 集成/解释的属性，以不显示）
  • 将安装选项的列表合并到一个“安装”按钮中，让 YAST 弄清楚使用哪个仓库，它会自动执行。因为当前的发行版列表很复杂（需要后台更改）。一个安装到正在使用的发行版的按钮。无论它是 Leap、Tumbleweed。如果这样做，这将大大改善用户体验。
    • 建议对 ymp 格式进行重新设计，以增强 openSUSE 用户的安装可用性。Software.o.o. 使用 YaST MetaPackage（这是 software.o.o. 用于生成一键安装的东西），但它不适用于其他软件包管理器，如 zypper 或 dnf。只有 YAST。重新设计 ymp 的解决方案将允许仅搜索您发行版的仓库，并让用户减少出错的机会。例如，像在 Leap 系统上安装 Factory 软件包一样。
    • https://github.com/yast/yast-metapackage-handler
  • 让 software.o.o. 仅提供 openSUSE 软件，并使用 repositories.opensuse.org（或 repos.opensuse.org）提供所有软件和来自 https://registry.opensuse.org/ 的容器结果
    • 制作一个发行版选择器。默认设置为 openSUSE，然后使用按钮或下拉列表从列表中选择（对于使用 OBS 为其他发行版构建软件包的人）
    • 更突出地列出 openSUSE 发行版。也许将其他发行版标记为“非 openSUSE 发行版”系列。
  • 一个具有 OPI（OBS Package Installer）的适当用户界面将允许选择软件包并在系统中有效地安装。
  • 考虑为软件.o.o. 编写一个 API，供那些可能对其感兴趣的人使用它来编写软件包管理解决方案。
  • 在 scc.suse.com 上搜索软件包。还有 CLI（zypper）和 GUI（YaST）客户端，SCC 提供了一个 API，因此您可以在所有地方看到相同的结果
  • 增强 openSUSE 品牌，以便软件包突出显示 openSUSE 软件包。
  • 通过一致的质量和品牌增强视觉界面，使用屏幕截图或徽标。
  • 允许使用 Open Build Service 的人员附加个人资料和关于 software.opensuse.org 上的软件信息。（姓名、电子邮件、github 帐户、简介、博客、图像等）
    • GDPR 选择加入和选择退出
    • 为开发人员/软件包项目提供一个个人资料图像和网站链接字段的选项
  • 优化软件包搜索过滤器。
  • 创建一个可以推动社区自助支持的界面。例如，带有可以指向论坛、邮件列表、错误报告、youtube 页面、reddit 页面等的评论的界面。可以发布信息，并且对软件包和评论的评级选项可以帮助企业和开源社区有效地协作。
  • 利用 software.o.o. 功能/API 为 SLE 和/或 PackageHub 提供的解决方案
  • 可能使用 DocTeam 的配方和 API。
  • 可以使用颜色系统来表示维护者、软件包和用户专业知识的信任度。
  • 让网站检测发行版。用于检测发行版和版本的 shell 脚本。
  • 与维护者(s)建立通信渠道
  • 该网站存在一些令人困惑的行为。某些软件包上会随机出现一个 AppStream 按钮，这会使用户感到困惑。“官方发布” [Official] 没有显示 Leap 15.3，并显示一些 AppImage 软件包为“官方发布”
    • 选择软件包类型，如 rpm、deb、AppImage 和 FlatPak

涉及的团队

  • Packaging Team：提供有关交互和反馈循环的打包专业知识
  • Release team 必须部署配置
  • YaST 团队可以帮助删除一键安装程序，并帮助使用 shell 脚本来识别正在使用的发行版。（需要更多研究和讨论，了解如何扩展软件包管理支持）
  • UI/UX 团队可以提供用户体验和原型。了解客户路径并在实践中优化它。
  • PackageHub：将资源与商业案例联系起来。
  • SCC 需要参与或至少提供一些反馈，这可能会帮助他们进行业务逻辑。
  • 维护者是当前维护者的主题专家。
从 "https://en.opensuse.net.cn/index.php?title=openSUSE:DyadProposal&oldid=169163" 检索