以下は、Sambaのソースコードを変更することとそれをSambaのメインブランチに 組み込むことに興味がある場合に便利かもしれない、いくつかのTIPSと注意事項である。
Sambaにコードを寄贈するために、最新のソースを得ておく必要がある。 Samba HOWTOコレクションの付録に記載されているGIT(訳注:オリジナルはCVS) からソースコードを検索する。
大量の変更を行うときには、Sambaチームのメンバーと相談してほしい。 Sambaコードのある部分は、1人またはそれ以上の'担当' - すなわち 大半のコードを書き維持しているSamba開発者がいる。
この方法は余計な時間と、他の誰かが同じ事を作業しているか、 作成した実装が正しいものではないという理由で、Sambaのメインブランチに 入れられない、何らかの作業を行うのを防ぐことが出来る。
Sambaツリーへのパッチはunified diff形式にすべきである。
たとえば、diff -u
によって生成されたファイルである。
もしもCVSから検索したSambaのコピーを修正しているならば、
cvs diff -u
を実行することによりそれらの変更の
差分を生成することが簡単にできる。
他の場所から単純にコピーして、動くまで、 それを変更してはならない。コードはきれいで論理的である必要がある。 重複したコードは拒否される。
パッチをテストすること。提供されたパッチを、Samba Teamの 誰かが評価する前にしばらく時間がかかるかもしれないので、 提供されたパッチが、再びレビューサイクルを通過する事が必要な時 より前に長い時間がかかるかもしれない。
1つの大きなdiffファイル中に分離されたパッチを入れないこと。 これは、読解とテストが困難になる。誰かが問題を抱えているものと混合する という理由で、コミットされた良いパッチを得られないというリスクに なるかもしれない。
coding-suggestionsの章で推奨されているような Sambaのコーディング形式に従うようにすること。
Sambaにおける、バグに対するバグ修正は、バグの説明の所 にあるような、Sambaの バグジラシステム を使って投稿すべきである。
新規機能のパッチが何をするかについての説明と共に、パッチを Samba-technicalメーリングリスト に投稿し、可能であれば、変更するコードの部分の、 Sambaチームメンバーの'担当'(のだれか)にも送ること。 Sambaチームメンバーは常時忙しいので、皆が、'他の誰かの1人にそれを処理させる' 傾向がある。もしも1週間経っても誰も反応しないのであれば、Sambaチーム のだれかから反応があるまで、再送すること。
Sambaチームの誰かはパッチを確認し、コミットするか、なぜそうしなかったかについての コメントを出すだろう。後者の場合、パッチを修正し、パッチが 受け付けられるまで再度提出することが出来る。