Where should things live?
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 領域
- build-system, release
調査の方向性
まず、issueで提案されているdeb/rpmのspecとルールの2つの配置場所を、記載されている長所・短所と、リンクされた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
- フォーク
- 38
- 平均マージ
- 2日 1時間
- マージ済み PR（30日）
- 14
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 1週間以上 初心者へのやさしさ 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 件 ·
メンテナーはふだん 1 日以内に返信
docker/packaging の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Install fails with pnpm: ERR_PNPM_IGNORED_BUILDS from auto-installed peer-dependency build scriptsオープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
mitsuhiko/agent-stuff#64 · コメント 1 件 ·
-
Priority
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
canonical/chisel-releases#1328 ·
メンテナーはふだん 1 日以内に返信
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:other issue-rating: 🦞 diamond lobster no-stale P2
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
openclaw/openclaw#159861 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信