Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Where should things live?

Đang mở
  • Có gì không ổn?
#3 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Lĩnh vực
build-system, release

Hướng nghiên cứu

Bắt đầu bằng việc xem xét hai vị trí được đề xuất trong issue cho các spec và quy tắc deb/rpm, bao gồm các ưu điểm, nhược điểm được liệt kê và ví dụ đóng gói containerd được liên kết. Công việc được xem là hoàn tất khi đã đưa ra và ghi lại quyết định về quyền sở hữu repository, thời điểm cập nhật, việc kiểm thử, phạm vi hỗ trợ các distro và cách truyền đạt các thay đổi.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Dockerfile
Star
35
Fork
39
Merge trung bình
1 ngày 4 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của docker/packaging

Tất cả issue của docker/packaging

Issue tương tự

Thêm issue về Build System

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.