Provide a mechanism to avoid pulling tags from upstream
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
- 35/100
Hướng nghiên cứu
Bắt đầu bằng việc xem xét commit 09d7ab5602404692bebcad25eea2527f0b54e7ba và cách xử lý hiện tại của projects-list đối với upstream tag. Xác định cấu hình nên phân biệt các fork hướng đến việc đóng góp với các fork được duy trì nhưng đã đổi tên như thế nào, sau đó xác minh rằng cấu hình được chọn ngăn không cho upstream tag được kéo về mà không thay đổi hành vi mặc định đối với các fork thông thường.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
In 09d7ab5602404692bebcad25eea2527f0b54e7ba, I threw in a dirty hack to prevent pulling tags from upstream in the calendra project (mostly because I didn't want to figure out the git incantation). @bswck had a good suggestion to make a tag to represent this config.
Use case
A project has forked another project into a new name but still maintains and merges changes from upstream into the fork. That's what happened with workalendar → calendra. With such a fork, the maintainer likely has a different set of versions and thus probably doesn't want the upstream tags. Contrast that with a typical "fork" where the user is merely making a private clone of the repo to accommodate GitHub workflows for contributions.
Design considerations
Presumably, there should be a simple and straightforward way to distinguish these two cases in the projects list.
One way might be to simply add a new tag "no-tags" or similar to indicate that a project should avoid pulling tags from upstream. Another might be to make that the default and require "tags" to indicate when upstream tags should be pulled. Given that pulling tags is the default and probably more common scenario, it would seem preferable to have "tags" be the default.
Another way to think about it is to model the two classes of fork, a "clone" and a "fork", where the former is the typical contribution-oriented fork and the latter is the properly forked project. That would require changing the purpose of the already established "fork" tag to mean something different. One potential advantage to this approach is that it's modeling the user's intent at a higher level and may have benefits down the line for other behaviors.
- Ngôn ngữ chính
- Python
- Star
- 7
- Fork
- 5
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của jaraco/jaraco.develop
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
jaraco/jaraco.develop#27 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
jaraco/jaraco.develop#22 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
jaraco/jaraco.develop#8 · 4 bình luận ·
Tất cả issue của jaraco/jaraco.develop
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
AstrBotDevs/AstrBot#10720 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
fix(xiaomi): curated picker list still offers six ids that return 400 (plan-limited vs retired)Đang mởcause/upstream comp/cli P2 provider/other tool/file type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
NousResearch/hermes-agent#143900 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 85/100
WLAN-Pi/wlanpi-profiler#341 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 1 ngày