获取Gentoo!

GLEP 3: Ebuild维护者扩展GLEP

作者 Caleb Tennis <caleb@gentoo.org>
类型 标准轨道
状态 延期
版本 1
创建日期 2003-06-09
最后修改日期 2014-01-15
发布历史 2003-06-10
GLEP 源代码 glep-0003.rst

摘要

Gentoo 的 portage 树试图为尽可能多的软件包提供自包含的、易于使用和自动安装程序，这些软件包可以由开发者维护。

此 GLEP 提出允许非核心 Gentoo 开发人员被视为由核心 Gentoo 开发人员赞助的 ebuild 维护人员。该系统将允许 portage 中更多 ebuild 可用，并为这些 ebuild 提供活跃的维护人员。

此 GLEP 仅适用于包含提交软件包或更新 portage 中版本请求的基于 EBUILD 的错误。

动机

截至此 GLEP 的第一份草案，Gentoo 的 bugzilla 数据库中有 1387 个 EBUILD 错误请求。其中许多请求包含由错误报告者提交的 ebuild，它们只是在等待 Gentoo 开发人员赞助 ebuild 的提交。

基本原理

Gentoo 的 portage 树已经包含了当今可用的最流行的软件包 ebuild。许多团队负责维护 portage 树中的这些核心 ebuild。但是，对于不太常用的 ebuild，没有一个好的焦点来存放这些 ebuild。

例如，任何提交的 KDE 应用程序 ebuild 都将被路由到 KDE 团队。但是，KDE 团队可能不熟悉提交的 ebuild。一个新的图形化 MySQL 编辑器可能会提交给 MYSQL 团队，但该团队的成员可能都不熟悉或没有学习新程序将其提交到 portage 的意愿。

我们希望能够为 portage 中尽可能多的 ebuild 提供支持，并确保所有 ebuild 都有人负责维护。

向后兼容性

目前没有与本文档冲突的政策。

实现

传入的 ebuild 错误报告应继续按正常方式处理。

不包含附件 ebuild 的错误报告应标记为 NEEDINFO。应将一条要求用户创建并提交 ebuild 的消息附加到错误。

包含附件 ebuild 的错误报告应回复一条消息，询问报告者是否同意为 ebuild 和软件包提供维护和支持。

如果报告者不同意提供软件包维护，则错误报告应标记为 WONTFIX。

如果报告者同意提供软件包支持，则应将 ebuild 添加到 portage，并在 ChangeLog 中添加一条注释，表明报告者被视为该特定 ebuild 的维护人员。

与该 ebuild 相关的任何传入错误报告应继续按正常方式处理。ebuild 所属的团队应将 ebuild 的作者 CC 到邮件中。可选地，如果 docs-team 成员事先知道 ebuild 是由外部维护的，他/她可以将该人员添加到 CC 列表中。

安全性

至少，所有 ebuild 必须由处理提交的开发者进行审查。

在任何情况下都不应使用提交的摘要文件。开发者有责任根据实际下载的源代码创建摘要文件。

但是，仍然存在潜在的安全漏洞。处理安装的开发者应尽一切努力确保没有 ebuild、软件包或其他文件被破坏。

未来

目前关于重新思考 Gentoo portage 和 bug 处理的提案（也称为 Herds）仍在协商中。本文档作者打算随着 Herds 概念的成熟和稳定而逐步完善此 GLEP 的概念。

参考文献

[1]GLEP 2，Sample ReStructuredText GLEP 模板，Goodyear，（https://gentoolinux.cn/glep/glep-0002.html）