0

仕事で使用しているかなり大規模なオープン ソース プロジェクトで行ったプル リクエストについて、少し混乱しています。プロジェクトについては明かしませんが、ミッション クリティカルなシステムやアプリケーションのさまざまな側面を監視するために使用される、大部分がユーザーによって提出されたスクリプトの大規模なコレクションが含まれています。自分の作業に使用する必要がある、ユーザーが提出したシェル スクリプトを見つけましたが、いくつかの重大なバグがあり、文体的には大破でした。バグを修正し、スクリプトのほぼ全体をリファクタリングして、かなりクリーンな「bash フォーム」にしました。私はスクリプトに対してプル リクエストを行いましたが、プロジェクト リーダーは引用付きでパッチを拒否しました。

「これは主にコーディング スタイルの変更です。あなたの努力には本当に感謝していますが、その種のパッチを受け入れ始めても何も得られません。問題、つまり本当に修正が必要なものに焦点を当てるようにしてください。ありがとう!」

以下は、スクリプト全体で行った読みやすさのための bash コーディング スタイルの変更の例です。

- start_time=`date +%s%N`
+ start_time=$(date +%s%N)

これはオープンソース プロジェクトでは一般的ですか? 私がコミットしたほとんどのプロジェクトは私自身のものであり、スタイル的に悪いコードを常にリファクタリングしています。問題のスクリプトのようにコードが他の人によって使用される場合、ユーザビリティのリファクタリングは歓迎されるべきではないでしょうか? プロジェクトにはコーディング スタイル ガイドがないため、少し混乱しています。

4

3 に答える 3

2

バグを最初に修正し、スタイルの変更を後で行うように、パッチを分割しましたか? そうでない場合は、パッチも拒否します。ロジックを変更するパッチは、できるだけ小さく自己完結型にする必要があります。何を修正したかを理解しようとするときに、ロジックに影響を与えないようにするために、何十回ものスタイル変更を行いたいと思う人はいません。

于 2012-09-09T02:06:55.313 に答える
1

これは、オープンソース プロジェクトの間で一般的なことではありません。最近のプル リクエストから反例を 1 つ挙げます。

https://github.com/djcb/mu/pull/65

mu4e と呼ばれる mu の Emacs コンポーネントに関連するプル リクエストです。私の唯一の変更点は、プロジェクトからさらに多くの変数を編集できるようにすることでしたM-x customize(「編集 -> 設定」または「ツール -> オプション」に相当する Emacs)。プログラム ロジックの変更はまったくありませんでした。ご覧のとおり、プル リクエストはわずか 2 時間で大騒ぎすることなくマージされました。(私はこれまでこのプロジェクトに貢献したことがなかったので、過去の貢献などに基づいて迅速に追跡されることはありませんでした。) これは、クレームなしで喜んで受け入れられた表面的な変更のみのプル リクエストの一例です。

問題のプロジェクトがあなたのパッチを拒否した理由については、おそらく彼らは頑固であるか、誇りを持って他の誰かがコードをいじったりすることを許していないだけかもしれませんが、一方で、表面的な非修正をマージしない正当な理由があります- ユーザー向けの変更。彼らがあなたのコードを受け入れ、少なくとも最小限の責任を負っている場合、少なくともあなたが行っているすべての変更を見て、何かを壊していないことを確認し、コードの変更がコミットログと一致していることを確認する必要がありますあなたが変わったと言っています。あなたのプル リクエストによって、多くのファイル全体で孤立した行またはブロックが大量に変更されたと思いますよね? これはおそらく、一括検索を実行してバックティックを次のように置き換えた場合の結果です$(). この種のパッチは検証が難しい場合があります。なぜなら、同じ変更を行ごとに見ると目が眩み、プロジェクト全体が壊れる原因となる閉じ括弧が欠落している 1 つのケースを見逃すからです。

要点は、無料でコードを提供していても、実際にコードをマージするのは無料ではないということです。コードをプロジェクトに統合する作業は、そうしないと、信頼できないコードをマージすることになります。場合によっては、プロジェクトの所有者が、あなたの変更が改善すると主張するものを見て、それらの改善は責任ある方法でコードをマージするために必要な努力を正当化しないという合理的な決定を下すことがあります。同意しない場合は、自由に独自のフォーク (「敵対的な」フォークではなく、ありふれた「Project X with my customs」フォーク) を作成し、そこに変更を加えて、自分で使用することができます。あなたの変更が本当に価値がある場合、人々はあなたのフォークに切り替え始めるかもしれません。その時点で、元の開発者は自分たちの立場を再考し、最終的にあなたの変更をマージするかもしれません.

于 2012-09-09T02:29:07.400 に答える
0

各プロジェクトには独自のルールとガイドラインがあります。このプロジェクトは、あなたが取り組んでいたものとは異なるルールで機能すると言われました。貢献したい場合は、彼らのルールに従わなければならないようです。(私は討論であなたの側につく傾向があります — しかし、私が担当していないときは、担当者のルールに従います!)

于 2012-09-09T02:03:04.647 に答える