Differences between revisions 23 and 24

Deletions are marked like this. Additions are marked like this.
Line 37: Line 37:
 * 至少在开始时我们会(差不都)每周在 irc.freenode.net 的 #centos-devel 频道上举行会议  * 至少在开始时我们会(差不都)每周在 irc.freenode.net 的 #centos-meeting 频道上举行会议
Line 223: Line 223:
~-Translation of revision 53-~ ~-Translation of revision 54-~

软件选集 SIG

SIG 状况:已获批准

协助引导程序的委员会成员:JimPerrin

软件选集 SIG 将会为上游提供空间开发各种软件选集及相关工具。开发者可以建基于及扩展现有的 SCL,这样他们便无须重蹈复辙,或不必要地负起包装依赖性组件的责任。

目标

  • SoftwareCollections.org 充当上游的 git 库。

  • 与开发者合作,接纳针对新软件选集的贡献。
  • 订立发行用的管理机制,成为创建/签署/发行的关闸。
  • 创建,并通过 centos.org 及 SoftwareCollections.org 发行软件选集。

  • 与 OpenShift Origin 及 foreman 等上游机构合作,提供兼容性。

资源需求

邮件列表及通讯

有关 CentOS 资源的工作及相关讨论将会在 centos-devel 邮件列表上进行。所有将于 SCL、用户之间的交互及上游的开发将会在现有的软件选集邮件列表上进行。

此 SIG 一般亦会在 irc.freenode.net 的 #centos-devel 频道上出现。

同步会议

  • 至少在开始时我们会(差不都)每周在 irc.freenode.net 的 #centos-meeting 频道上举行会议
  • 现时会议在星期三 4pm UTC 举行
  • irc 会议的请柬一般会于一天前同时发送到上述的两个邮件列表

特别兴趣小组内容

有关所有组合及停止支援期请参阅 选集清单

如欲进一步获取某软件选集的资料,请在 http://softwarecollections.org 搜寻该选集。

我们会针对套件进行 CIhttps://ci.centos.org/view/SCLo-pkgs-cbs/

特别兴趣小组成员

软件选集 SIG 将会有一个督导委员会及多名软件提交者。督导委员会最初计有:

其它成员的清单已收录于 https://accounts.centos.org/group/members/sig-sclo

督导委员会有权增加软件提交者及成员。督导委员会将会通过引导程序的委员会成员与 CentOS 委员会接口。

软件提交者的权限,一经获取便不会到期,除非由督导委员会所撤消。

投身参与

给多产贡献者的提示

路线图及引导程序

  • 初步定义组件集及发行二元档
  • 订立 git 工作程序
  • 定义接纳贡献的条件
  • 为社群的用户及贡献者提供文档
  • 订立提交错误报告的政策/惯例
  • 设立发行周期及升级政策

项目清单

待办清单内有下列项目:

  • 为 RHEL 准备发行组件,好让 RHEL 用户能从 sclo 命名空间安装软件选集

  • 实施 authtag 以便能配合 dist-git 存储软件选集的 SRPM
  • 预备好 dist-git 后,我们想利用 SCM 创建 SRPM,但在 sclo/ 名称空间下是不可能的,因此我们需要创建一些工具,省却手动输入 rpms/ 名称空间的步骤
  • 为建基于软件选集的 docker 映像创建子网页

新增软件选集的步骤

  1. 熟集包装 SCL 套件的 包装守则

  2. 自我介绍,然后在邮件列表建议新增一个软件选集 sclorg@redhat.com

  3. 遵照 「投身参与」步骤 申请成为特别兴趣小组成员

  4. 遵照 下文 申请标签

  5. 遵从 建立套件 的步骤

  6. 考虑为你的选集编写测试并将它们放入 CI

  7. http://softwarecollections.org 加入项目

  8. 更新 SCL 清单页 上的软件选集清单

  9. 首先在 centos-devel 邮件列表 宣布在 buildlogs 上收录了新的软件选集,然后当镜站准备好后,再在 centos-announce 邮件列表 上宣布

  10. 在网志、相关的(上游)邮件列表或社交媒体上推广你的选集

(若要在任何步骤取得协助,请与特别兴趣成员联络)

申请 CBS 标签及目标

假若你要为新的软件选集创建标签及目标,请遵从以下步骤:

继承 CBS 标签

有时候某个 SCL 需要(于创建或执行时)采用来自另一个 SCL 的组件。创建 SCL 用的目录内一般不会含有该 SCL 以外的组件,因此我们须要申请继承特定的标签(例如当创建 MongoDB SCL 的某些组件时需要采用 Maven SCL,MongoDB 的标签须要继承 Maven SCL 的组件)。若要申请继承标签,维护者必须递交这样的申请:https://bugs.centos.org/view.php?id=10525

个别标签的继承清单已收录于: https://git.centos.org/blob/sig-core!cbs-tools.git/master/scripts!sigs!sclo!sclo-inheritance.sh

为软件选集创建组件

源代码软件库

软件选集暂时仍未有 dist-git 源码库,但不少组件的源码已收录于 https://github.com/sclorg-distgit

创建组件

我们可如此直接创建组件:

cbs add-pkg sclo7-rh-mariadb100-rh-candidate --owner=sclo rh-mariadb100-mariadb
cbs build sclo7-rh-mariadb100-rh-el7 rh-mariadb100-mariadb-10.0.18-1.el7.src.rpm

建成后,CI(持续整合流程)将会为我们测试完整性,接著我们可以为它们加上 -testing 软件库的标签:

cbs add-pkg sclo7-rh-mariadb100-rh-testing --owner=sclo rh-mariadb100-mariadb
cbs tag-build sclo7-rh-mariadb100-rh-testing rh-mariadb100-mariadb-10.0.18-1.el7

发放组件至 testing 软件库

http://buildlogs.centos.org/centos/7/sclo/x86_64/ 有一个工作流程会自动把所有标签为 -testing 的组件放进 testing 软件库内。

若要采用这方法,每个软件集在头一次都必须被加进该工作流程内,做法就是创建这样的申请:https://bugs.centos.org/view.php?id=10260 。然后,用户便可通过安装及启用以下其中一个软件库来安装组件:

yum-config-manager --enable centos-sclo-rh-testing
yum-config-manager --enable centos-sclo-sclo-testing

发行组件

当我们要发行套件时,步骤就如发放至 testing 软件库一般。 这些套件必须在 -testing 标签/软件库内逗留最少一至两个星期才可以发行。

  1. 为套件加上 -release 标签:

cbs add-pkg sclo7-rh-mariadb100-rh-release --owner=sclo rh-mariadb100-mariadb
cbs tag-build sclo7-rh-mariadb100-rh-release rh-mariadb100-mariadb-10.0.18-1.el7

以下步骤只适用于首次发行的选集,更新选集时应被省略:

  1. 签署并发行套件至 http://mirror.centos.org(如 https://bugs.centos.org/view.php?id=9838 般申请)

  2. https://lists.centos.org/pipermail/centos-announce/ 上发出公布(例如 https://lists.centos.org/pipermail/centos-announce/2015-December/021577.html

    • 我们须要为 CentOS 6 及 CentOS 7 个别发出公布
    • 我们必须测试公布内的步骤是可行的

在SCLo 采用 EPEL 的组件

这只限于 sclo- 名称空间,即是那些并非源于 RHSCL 的软件选集。

SCLo 的建设过程是不能直接采用 EPEL 组件的,因为 CBS 只提供 CentOS 组件。因此,EPEL 组件必须在 CBS 下重建。然而,重建这些组件有很多方法(现时的推荐):

我们想避免 SCLo 与 EPEL 组件之间的冲突而引发的依赖性恶梦(不同组件依赖同一组件的不同版本)。

1. 把 EPEL 组件转变成某个软件选集的一部份

  • 此技术确保能避开 EPEL

2. 包装为正常组件

  • 我们必须确保版本与 EPEL 一致
    • 如果要 EPEL 6 及 7 提供同一版本或许会有难度(见下文「混合方案」)
    • 收录在 sclo-common 标签下(sclo7-common-el7 目标)

3. 在 SCLo 软件库内把 EPEL 组件重新命名

  • 通过重新命名,能避免与 EPEL 组件发生冲突
    • 组件依然通用于各软件选集
    • 所有软件选集必须只采用单一版本

4. 混合方案(例如:为 EPEL 6 重新命名,保留 EPEL 7 的正常组件)

软件选集名称解构

软件选集的名称是由作者选择的惯用标识码,亦不应该被分拆为个别部件。

然而,由于多数名称是根据某些指引而制定,下面就以 scol-vagrant1 软件选集为例:

  • <sclo>:选集名称的前缀并非用来局限它于特定发行版本,而是作为它的「名称空间」。来由 Red Hat Software Collections 的软件选集采用 rh- 这个前缀;而由社群所创建的软件选集以 sclo- 作为前缀。

选集名称的前置:

  1. 容许「其他人」(尤其是用户)按他们的需要设立特定的名称
  2. SCL 作者能在选集出现之处采用单一个「选集名称」
  3. 用户(是开源计划好、是付款者也好)不论在哪一个平台都能针对单一个选集名称

更多有关前置的资料:https://www.redhat.com/archives/sclorg/2015-February/msg00022.html

  • <vagrant>:这是主要附带的应用程序。一个选集很多时包含大量的支持组件。譬如说:php 选集内含有大量 php 扩展组件和 pear 模块,它们都在同一个软件选集下以相同名称发行。

  • <1>:这是主要版本编号,也作追踪 abi 之用。例子包括 ruby197、ruby200 等

更多信息

Translation of revision 54

zh/SpecialInterestGroup/SCLo (last edited 2019-08-08 09:54:27 by TimothyLee)