Where should things live?
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 领域
- build-system, release
调研方向
先审阅 issue 中提出的两个 deb/rpm spec 和规则存放位置，包括列出的优点、缺点以及链接的 containerd 打包示例。完成的标准是就仓库归属、更新时机、测试、发行版覆盖范围以及如何传达变更作出决定并记录下来。
由索引模型根据 Issue 内容生成。
描述
Just a random ticket with a comment I wrote on slack;
I'm still undecided where the specs/rules would live best.
deb/rpm specs and rules in each repository
- PRO it's more "standard"? (people could build from the repo using standard tooling if it's in the expected location)
- PRO repo maintainers can also update the spec/rules if things change in the source/project
- PRO repo maintainers can test packaging before releasing
- CON is that repo maintainers now must update spec/rules if things change in the source/project (and packaging is an expertise not everyone knows all details about)
- CON is that ^^ if fixes are needed for packaging (in the spec/rules), those now require a new release
deb/rpm specs and rules in a central repository
- PRO maintainers with expertise on packaging (and all its quirks) can maintain the specs/rules, applying "best practice" and consistency
- PRO "packaging only" updates to specs/rules can be made independently of project releases (which includes changes to packaging related to "new distros added" or "EOL distros removed"
- CON less standard? (deb and rpm tools work well with specs/rules living together with the source?)
- CON when do we test packaging? We may discover issues after projects did a release.
- CON maintaining the files would become a shared responsibility, and maintainers of the packaging repository may not be notified / may not be aware when things change in project repositories.
- CON less likely to receive contributions
- PRO/CON central place to maintain the list of distros to package for (but could be communicated to the projects in other ways)
TBD how often the specs need updates; might be less complicated for CLI tools, but of course the devil is in the detail; some changes may be distro-specific, not due to changes in the project. Thinking of things like; https://github.com/docker/containerd-packaging/blob/6e368fae00d9e02d7eca6f751416c026516ece98/rpm/containerd.spec#L54-L57
TL;DR; either way makes sense, either way has pros/cons
- 主要语言
- Dockerfile
- 星标
- 35
- 派生
- 39
- 平均合并
- 2 天 12 小时
- 30 天内合并 PR
- 14
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
docker/packaging 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 1 天内回复
-
area/pkg/agent area/pkg/buildx area/pkg/compose area/pkg/containerd area/pkg/docker-cli area/pkg/docker-engine area/pkg/model
难度 5/5 一周以上 新手友好度 28/100
docker/packaging#316 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 52/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
docker/packaging#348 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 45/100
docker/packaging#326 · 1 个 reaction ·
维护者通常 1 天内回复
相似的 Issue
-
good first issue needs-triage priority: medium
难度 2/5 1-3 小时 新手友好度 72/100
melodic-software/claude-code-plugins#7014 · 1 条评论 ·
维护者通常 1 天内回复
-
0.kind: enhancement 9.needs: package (update)
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 62/100
hpi-swa-teaching/AutoTDD#135 ·
-
bug pixi-build-r
难度 2/5 1-3 小时 新手友好度 70/100
prefix-dev/pixi#7229 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
mesonbuild/wrapdb#2961 ·
维护者通常 1 天内回复