Provide a mechanism to avoid pulling tags from upstream
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
まずコミット 09d7ab5602404692bebcad25eea2527f0b54e7ba と、upstream タグに対する現在の projects-list の処理を確認します。次に、設定で貢献目的のフォークと、名前を変更して保守されているフォークをどのように区別すべきかを決め、選択した設定によって、通常のフォークのデフォルト動作を変更せずに upstream タグが取得されないことを検証します。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Python
- スター
- 7
- フォーク
- 5
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
jaraco/jaraco.develop のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
jaraco/jaraco.develop#34 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
jaraco/jaraco.develop#27 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
jaraco/jaraco.develop#22 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
jaraco/jaraco.develop#8 · コメント 4 件 ·
jaraco/jaraco.develop の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
MISP/misp-workbench#496 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
fossasia/visdom-dev#69 ·
メンテナーはふだん 3 日以内に返信
-
[Bug] Parameters named like a property break to_xcal()対応中かも @atharvasalunke1267 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
collective/icalendar#2018 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信