Azure Linux コードに貢献する

Azure Linux ソース リポジトリはパブリックであり、標準のオープン ソース プル要求 (PR) ワークフローに従います。 この記事では、Azure Linux コードに貢献する方法について説明します。たとえば、PR の送信、バグの修正、Azureシナリオでの Azure Linux の新機能の追加などです。

Important

コードコントリビューションは、Azureサポートされているシナリオをターゲットにする必要があります。 Microsoftのサポートとライフサイクルのコミットメントは、次の場合にのみ適用されます。

  • Azure Linux Virtual Machines (VM) / Virtual Machine Scale Sets (VMSS)、AKS コンテナー ホスト、およびコンテナー イメージ。
  • 事前構築済みのAzure Linux イメージの上に構築されたカスタマイズ (たとえば、Image Customizer)。

ベアメタル、オンプレミス、その他のクラウド、または GitHub 上の Azure Linux ソース から一から構築されたイメージに固有の変更は、アップストリームに属します。 代わりに、アップストリームプロジェクトまたは Fedora Linux Project に貢献することを検討してください。 詳細については、「Azure Linux に貢献する方法を参照してください。

Note

Azure Linux 4.0 は現在、preview であり、評価とテストの目的に厳密に限定されています。 運用環境での使用には適していません。

始める前の準備

すべてのコード コントリビューションには、最初に問題が必要です。 メンテナンス担当者の承認済みで、関連する問題がリンクされていない場合は、PR を開かないでください。 事前の問題の承認なしで送信された PR は、レビューなしで閉じられる可能性があります。

投稿のベスト プラクティス

Azure Linux にコードを提供する場合は、次のベスト プラクティスに従って、PR を効率的に確認し、正常にマージできるようにします。

  • アップストリーム優先モデルに従います。 Azure Linux で PR を開く前に、変更がアップストリームに属しているかどうかを確認します。
  • チームが方向とスコープを確認できるように、簡単でない作業を開始する前に問題を開きます。
  • PR を小さくし、集中する。 PR ごとに 1 つの論理的な変更。
    • 送信する変更が大きい場合は、最初に問題を提出して、完全な変更を実装する前に、スコープとアプローチについて話し合います。
  • 新しい動作を追加したりバグを修正したりするときに、テストまたは検証の証拠を含めます。
  • PR の説明欄に、関連する課題とアップストリームへの提出を記載してください。
  • 機能変更のみを行う PR を送信します。 動作を変更せずにコードのスタイルを変更または再フォーマットするだけの PR を送信しないようにします。

Azure Linux にコードを提供するには:

  1. 行いたい作業に対する課題を作成または見つけます。 作業を開始する前に、メンテナーが問題を承認するのを待ちます。 既存の問題がシナリオに対応している場合は、コメントして作業を行う必要があることを示します。
  2. GitHubにリポジトリをフォークします。
  3. わかりやすい名前 ( など) を使用して、mainのfeature/tool-loggingします。
  4. 変更を行ってコミットします。 明確で簡潔なコミット メッセージを記述します。
  5. 変更をテスト し、ビルドがクリーンであることを確認します。
  6. 。 PR テンプレートを完全に入力し、関連する問題をリンクし、変更内容とその理由を説明します。
  7. フィードバックに応答します。 保守担当者は変更を要求する場合があり、複数のリビジョン ラウンドが一般的です。
  8. 承認を待ちます。 承認されると、PR がマージされます。 この手順のタイムラインは保証されません。

共同作成者使用許諾契約書 (CLA)

ほとんどの投稿では、共同作成者使用許諾契約書 (CLA) に同意し、投稿を利用する権利を私たちに実際に付与することを確認する必要があります。

PR を送信すると、CLA ボットは CLA を提供する必要があるかどうかを自動的に判断し、それに応じて (たとえば、状態チェックやコメントを追加して) PR を更新します。 ボットが CLA が必要であることを示す場合は、PR をマージする前に、CLA プロセスを完了するために提供される指示に従います。 これは、Microsoft CLA を使用して、すべてのリポジトリで 1 回だけ行う必要があります。

レビュー中に想定される内容

  • レビューは可能な範囲で行われます。 保守担当者は、容量が許す限り貢献度を確認します。 タイムラインは異なる場合があります。
  • 同意は保証されません。 すべての PR がマージされるわけではありません。 別のアプローチを提案したり、最初にアップストリームを送信するように依頼したり、変更が範囲外であると判断したりする場合があります。
  • リダイレクトする場合があります。 アップストリーム プロジェクトまたは Fedora に適した変更の方が適している場合は、お知らせし、適切な場所を見つけるお手伝いをします。
  • 小さい PR の方が高速に移動します。 明確な問題ステートメントと再現可能な検証による焦点を絞った変更は、最も簡単に確認できます。
  • 古い PR は閉じられます。 アクティビティが 30 日間ない PR は、自動的に閉じられる場合があります。 PR の作業を続行する場合は、再度開くことができます。

関連するコンテンツ

Azure Linux への貢献の詳細については、「Azure Linux に貢献する方法を参照してください。

  • Last updated on