バグ修正パッチは誰の責任ですか？
オープンソースプロジェクトで数回発生した状況は次のようになります。
- デプロイメントのバグに気づき、簡単なハックパッチを見つけました。 （たとえば、実際には不要なコードをコメント化するだけです。）
- 私は本当のバグを理解し、パッチを考え出し、Gitプルリクエストなどを介してそれを提出するために少し余分な労力を費やしています。
- プルリクエストが拒否されました。おそらく、パッチは不完全だった（たとえば、含まれてはならない行が含まれていた）、おそらくコーディングスタイルに違反した、おそらく他の影響があった。あるいは、Gitで何か間違ったことをしたのかもしれません-プルリクエストはリベースされたはずです。メンテナはパッチを改善する方法についてフィードバックを提供し、私がそれを再提出するように要求します。
この時点で、私はどこまで進めるべきかについて混乱しています。私に関する限り、問題はありません。問題をステップ1で修正しました。問題を報告しました。他の人のために問題を修正するための手順を実行しました。しかし、それは「私の」プルリクエストだとは思わないので、パッチを改善する責任が私にあるとは思わない。
私をいらいらさせる特定の状況の1つは、私のパッチの失敗について話し合った後、正しいパッチがどうなるか（つまり、コードのすべての行が記述されていることもある）についてメーリングリストで合意に達したことです。その場合でも、実際にパッチを生成して送信するのは私の責任であると考えられます。
これらの状況で標準的なエチケットはありますか？それらはどのように解決されますか？私の反応は異常ですか？バグ修正を受け入れるまでにどれくらいの時間がかかると予想されますか？
（私が「オープンソースプロジェクト」と言うとき、これらのいくつかは非常に小さいですが、趣味ではないかもしれません-いくつかの組織で使用されている小さなソフトウェアプロジェクトで、開発者のリソースに取り組んでいます。明らかな答えの場合「パッチを修正して再提出する」です。私は雇用者に彼らにとって有益なものに取り組む責任があることを理解してください。私たちに影響を与えないバグの修正に時間をかけるのは間違っているでしょう...）
私に関する限り、バグを発見したり、機能強化のリクエストがあり、プロジェクトへの貢献者ではなく、適切なチャネルを通じて欠陥レポートを提出した場合は、完了です。コミュニティへの還元という点では、オープンソースプロジェクトを使用していて欠陥を見つけた人は誰でもそれを報告する必要があります。
ソリューションを見つけて設計し、実装することは、プロジェクトのボーナスです。これを実行した場合は、プルリクエストを介して、またはファイルデルタを開発チームに欠陥レポートまたは拡張リクエストと一緒に送信して、何かを処理するために提出することをお勧めします。ただし、プロジェクトへの貢献を受け入れる義務はありません。
ユーザーにパッチの提供を期待することは、私には間違っているようです。問題に関するディスカッションに参加するのはかなり簡単ですが、解決策を考え出すのははるかに長い時間の投資です。単一の問題を修正するためだけに、非貢献者が貢献者になることを期待するプロジェクトはありません。
我慢できる限り進んでください。パッチを修正してメイントランクの世界と共有するのは良いことですが、メンテナが望んでいない場合は肩をすくめて。同じ場所にいる他の人が解決策を探すことができるように、問題のどこかに投稿し、それを処理するためのパッチを作成できます。
そして、あなたは問題がないわけではありません。 パッチは次のアップグレードには含まれません。したがって、新しいバージョンを取得するたびに、再パッチし、機能することを確認するか、パッチを適所にマッサージする必要があります。したがって、それをメインプロジェクトに取り込むことで、長期的にはあなたとあなたの会社の時間を節約できます。
それはあなたにとって苦痛ですが、あなたはコミュニティに貢献しています。私は確かにすべての貢献者が行った仕事に感謝します。それは単に魔法のように大衆から創られた質の高いソフトウェアのようなものではありません。誰かがその仕事をしなければならない。 （それで、誰が素晴らしいのですか？あなたは素晴らしいです）。気が進まない場合は、どうあるべきかについての議論に感謝する一方で、忙しくてそれを行うことができないことをコミュニティに知らせてください。つまり、彼らは何をするのでしょうか？賃金を下げますか？
オープンソースの文化を理解しやすくする1つの原則があります。それは、作業を行う人が作業する内容を決定することです。これは、開発者の日常業務に比べて魅力の1つです。あなたの＃1優先順位は、バックログで＃50かもしれません。プルリクエストを修正しない場合、最終的にはたぶんトップに細流し、彼らはそれを処理します。しかし、あなたが彼らのために十分に簡単にするなら、彼らは今それを世話します。
プルリクエストを修正するように求められるもう1つの理由は、より大げさです。彼らはあなたにあなたの貢献に対する信用を得てほしいと思っています。修正を行う場合、あなたの名前はコミットの作者フィールドにあるものです。ほとんどの人はそれを見たいと思うほどの貢献に誇りを持っているので、メンテナーのデフォルトの手口はそれらを許可することです。
あなたの雇用主に対するあなたの責任の限りでは、あなたのビジネスがこのコードに依存しているならば、あなたは彼らを害することはしません。雇用主は、工具を研ぐのに時間をかける職人の利点を知っています。
私の知る限り、オープンソースの方法は、バグを修正する責任は、バグを確実に修正するための負担を処理するためにバグを十分に気にする人に任されているということです。状況に応じて、問題を単に無視することから戦い（パッチを提供し、それらが受け入れられるように議論すること）まで、すべて修正して確実に修正しました。
すべてが正しい、プロジェクトを管理している人々にあなたからの間違ったことを期待させないでください（つまり、ディスカッションオプションによって問題を適切に修正し、何もしないことを彼らに期待させます）、おそらく彼らは彼らよりも多くの問題を認識しています自分自身を処理することができ、可能であればあなたの継続的な貢献者を作ろうとします。
オープンソース開発者にとって、問題には2つのタイプがあります。
- （a）パッチなしの問題
- （b）パッチによって引き起こされる問題
ほとんどのオープンソースパッケージのメンテナ/開発者は、コア以外の寄稿者がパッチを迅速に入手できるように支援するアイデアが大好きだと思います。
ただし、その主な目的は、タイプBの問題の数を最小限に抑えることです。そのため、バーはかなり高く設定されています。
一部の人々はそれを乗り越えます。彼らは貢献者、あるいはおそらくコア貢献者になります。その他はあきらめます。オープンソースには特定のダーウィンの性質があります-適者生存。
私はあなたがチームがそれを受け入れるまで、あなたの貢献を押して、輝かせることをお勧めします。いくつかの貢献をすると、彼らはあなたをさらに信頼しますが、貢献が申し分のないものであることを確認する必要があります。
最終結果は完全に価値があります。 「コードを書くのですか？はい...あなたは私が書いたものを毎日実行しています」
元のバグはあなたにのみ影響を与える可能性があるため、パッチを準拠させるために必要なあらゆることを実行して提出を取得することは非常に重要です。そうしないと、次にプルするバージョン（他の修正が必要なため）には修正がありません。
プロジェクトの新しいコピーをプルするたびに適用する必要のあるパッチのリストを維持したくない-それはあまりにも面倒です。もう少し時間をかけて、永続的に修正してください。これで、再度対処する必要がなくなります。