Proses Penerimaan Patch

Diupdate tiap hari · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

Halaman ini menguraikan cara kontributor dapat menyarankan dan melakukan perubahan pada basis kode Bazel.

  1. Baca kebijakan Kontribusi Bazel.
  2. Buat masalah GitHub untuk membahas rencana dan desain Anda. Pull request yang mengubah atau menambahkan perilaku memerlukan masalah yang sesuai untuk pelacakan.
  3. Jika Anda mengusulkan perubahan signifikan, tulis dokumen desain.
  4. Pastikan Anda telah menandatangani Perjanjian Lisensi Kontributor.
  5. Siapkan commit git yang mengimplementasikan fitur. Jangan lupa menambahkan pengujian dan memperbarui dokumentasi. Jika perubahan Anda memiliki efek yang terlihat oleh pengguna, tambahkan catatan rilis. Jika perubahan tidak kompatibel, baca panduan untuk meluncurkan perubahan yang menyebabkan gangguan.
  6. Buat permintaan pull di GitHub. Jika Anda baru menggunakan GitHub, baca tentang permintaan pull. Perhatikan bahwa kami membatasi izin untuk membuat cabang di repositori Bazel utama, jadi Anda harus mengirimkan commit ke fork repositori Anda sendiri.
  7. Pengelola Bazel akan menugaskan peninjau kepada Anda dalam waktu 7 hari kerja (tidak termasuk hari libur di Amerika Serikat dan Jerman). Jika Anda tidak ditetapkan sebagai peninjau dalam jangka waktu tersebut, Anda dapat mengirimkan pesan ke @bazelbuild/triage di PR.
  8. Bekerja sama dengan peninjau untuk menyelesaikan peninjauan kode. Untuk setiap perubahan, buat commit baru dan kirimkan untuk membuat perubahan pada permintaan pull Anda. Jika peninjauan membutuhkan waktu terlalu lama (misalnya, jika peninjau tidak merespons), Anda dapat mengirimkan ping @bazelbuild/triage di PR.

  9. Setelah peninjauan Anda selesai, pengelola Bazel akan menerapkan patch Anda ke sistem kontrol versi internal Google.

    Tindakan ini memicu pemeriksaan pra-commit internal yang dapat menyarankan lebih banyak perubahan. Jika Anda belum menyatakan preferensi, pemelihara yang mengirimkan perubahan Anda dapat menambahkan perubahan "sepele" (seperti linting) yang tidak memengaruhi desain. Jika perubahan yang lebih mendalam diperlukan atau Anda lebih suka menerapkan perubahan secara langsung, Anda dan peninjau harus mengomunikasikan preferensi dengan jelas dalam komentar peninjauan.

    Setelah pengiriman internal, patch diekspor sebagai commit Git, dan pada saat itu permintaan pull GitHub ditutup. Semua perubahan akhir dikaitkan dengan Anda.