Catat Tanggalnya: BazelCon 2023 akan diadakan pada 24-25 Oktober di Google Munich! Pelajari lebih lanjut

Panduan untuk Penanganan Bazel

Laporkan masalah Lihat sumber

Ini adalah panduan untuk pengelola project open source Bazel.

Jika Anda ingin berkontribusi ke Bazel, baca Berkontribusi pada Bazel.

Tujuan halaman ini adalah untuk:

  1. Berfungsi sebagai sumber kebenaran pengelola untuk proses kontribusi project.
  2. Tetapkan ekspektasi antara kontributor komunitas dan pengelola project.

Grup kontributor inti Bazel memiliki sub-tim khusus untuk mengelola aspek proyek open source. Di antaranya:

  • Proses Rilis: Kelola proses rilis Bazel.
  • Tim Hijau: Kembangkan ekosistem aturan dan alat yang sehat.
  • Developer Experience Gardener: Mendorong kontribusi eksternal, meninjau masalah dan menarik permintaan, dan membuat alur kerja pengembangan kami lebih terbuka.

Rilis

Continuous Integration

Baca panduan tim Hijau untuk infrastruktur CI Bazel di repositori bazelbuild/continuous-integration.

Siklus Proses Masalah

  1. Pengguna membuat masalah menggunakan Template Masalah dan memasuki kumpulan masalah terbuka yang belum ditinjau.
  2. Anggota di rotasi subtim Pengalaman Developer (DevEx) akan meninjau masalah tersebut.
    1. Jika masalahnya bukan bug atau permintaan fitur, anggota DevEx biasanya akan menutup masalah dan mengalihkan pengguna ke StackOverflow dan diskusi Bazel untuk mendapatkan visibilitas yang lebih tinggi terkait pertanyaan tersebut.
    2. Jika masalah berada di salah satu repositori aturan yang dimiliki oleh komunitas, seperti rules_apple, anggota DevEx akan mentransfer masalah ini ke repositori yang benar.
    3. Jika masalah tidak jelas atau informasinya tidak ada, anggota DevEx akan menetapkan kembali masalah tersebut kepada pengguna untuk meminta informasi lebih lanjut sebelum melanjutkan. Hal ini biasanya terjadi jika pengguna tidak mengikuti Template Masalah.
  3. Setelah meninjau masalah ini, anggota DevEx memutuskan apakah masalah tersebut perlu segera diperhatikan. Jika ya, pemilik akan menetapkan label prioritas P0 dan pemilik dari daftar prospek tim.
  4. Anggota DevEx menetapkan label untriaged dan tepat satu label tim untuk pemilihan rute.
  5. Anggota DevEx juga menetapkan tepat satu label type:, seperti type: bug atau type: feature request, sesuai dengan jenis masalah.
  6. Untuk masalah khusus platform, anggota DevEx menetapkan satu label platform:, seperti platform:apple untuk masalah khusus Mac.
  7. Jika masalah berprioritas rendah dan dapat ditangani oleh kontributor komunitas baru, anggota DevEx akan menetapkan label good first issue. Pada tahap ini, masalah memasuki kumpulan masalah terbuka yang tidak diprioritaskan.

Setiap subtim Bazel akan melakukan triase pada semua masalah berdasarkan label yang mereka miliki, sebaiknya setiap minggu. Subtim akan meninjau dan mengevaluasi masalah tersebut dan memberikan penyelesaian, jika memungkinkan. Jika Anda adalah pemilik label tim, lihat bagian ini untuk mengetahui informasi selengkapnya.

Saat teratasi, masalah dapat ditutup.

Siklus Proses Permintaan Pull

  1. Pengguna membuat permintaan pull.
  2. Jika Anda adalah anggota tim Bazel dan mengirimkan PR ke area Anda sendiri, Anda bertanggung jawab untuk menetapkan label tim dan menemukan pengulas terbaik.
  3. Jika tidak, selama triase harian, anggota DevEx menetapkan satu label tim dan pemimpin teknis tim (TL) untuk pemilihan rute.
    1. TL secara opsional dapat menugaskan orang lain untuk meninjau PR.
  4. Peninjau yang ditugaskan akan meninjau PR dan bekerja sama dengan penulis hingga disetujui atau dihapus.
  5. Jika disetujui, peninjau akan mengimpor commit PR ke sistem kontrol versi internal Google untuk pengujian lebih lanjut. Karena Bazel adalah sistem build yang sama dengan yang digunakan secara internal di Google, kami perlu menguji semua commit PR terhadap rangkaian pengujian internal. Inilah alasan kami tidak menggabungkan PR secara langsung.
  6. Jika commit yang diimpor lulus semua pengujian internal, commit tersebut akan digabungkan dan diekspor kembali ke GitHub.
  7. Saat commit digabungkan menjadi master, GitHub akan otomatis menutup PR.

Tim saya memiliki label. Apa yang harus saya lakukan?

Subtim harus mengelompokkan semua masalah dalam label yang mereka miliki, sebaiknya setiap minggu.

Masalah

  1. Filter daftar masalah menurut label tim Anda dan label untriaged.
  2. Tinjau masalahnya.
  3. Identifikasi tingkat prioritas dan tetapkan label.
    1. Masalah ini mungkin telah diprioritaskan oleh subtim DevEx jika berupa P0. Prioritaskan kembali jika diperlukan.
    2. Setiap masalah harus memiliki tepat satu label prioritas. Jika masalahnya adalah P0 atau P1, kami menganggap bahwa masalah tersebut sedang ditangani secara aktif.
  4. Hapus label untriaged.

Perhatikan bahwa Anda harus berada di organisasi Bazelbuild agar dapat menambahkan atau menghapus label.

Permintaan Pull

  1. Memfilter daftar permintaan pull menurut label tim Anda.
  2. Tinjau permintaan pull yang terbuka.
    1. Opsional: Jika Anda ditetapkan untuk ditinjau tetapi tidak sesuai untuk Anda, tetapkan kembali pengulas yang sesuai untuk melakukan peninjauan kode.
  3. Bekerja samalah dengan kreator permintaan pull untuk menyelesaikan peninjauan kode.
  4. Setujui PR.
  5. Pastikan semua pengujian lulus.
  6. Impor patch ke sistem kontrol versi internal dan jalankan pra-pengiriman internal.
  7. Kirimkan patch internal. Jika patch berhasil dikirim dan diekspor, PR akan otomatis ditutup oleh GitHub.

Prioritas

Definisi prioritas berikut akan digunakan oleh pengelola untuk mengatasi masalah.

  • P0 - Fungsi utama yang rusak yang menyebabkan rilis Bazel (tanpa kandidat rilis) tidak dapat digunakan, atau layanan tidak aktif yang sangat memengaruhi pengembangan project Bazel. Ini mencakup regresi yang diperkenalkan dalam rilis baru yang memblokir sejumlah pengguna yang signifikan, atau perubahan yang dapat menyebabkan gangguan yang tidak kompatibel dan tidak mematuhi kebijakan Perubahan yang Dapat Menyebabkan Gangguan. Tidak ada solusi praktis.
  • P1 - Fitur atau kerusakan kritis yang harus ditangani di rilis berikutnya, atau masalah serius yang memengaruhi banyak pengguna (termasuk pengembangan project Bazel), tetapi ada solusi praktisnya. Biasanya tidak memerlukan tindakan segera. Dalam permintaan yang tinggi dan direncanakan dalam rencana jangka waktu saat ini.
  • P2 - Kerusakan atau fitur yang harus ditangani, tetapi saat ini kami tidak memprosesnya. Moderasi masalah langsung dalam versi Bazel yang dirilis yang merepotkan pengguna yang perlu ditangani dalam rilis mendatang dan/atau ada solusi mudah.
  • P3 - Perbaikan bug atau peningkatan kecil yang diinginkan dengan dampak kecil. Tidak diprioritaskan dalam rencana Bazel atau rilis segera, namun kontribusi komunitas sangat disarankan.
  • P4 - Kerusakan dengan prioritas rendah atau permintaan fitur yang cenderung tidak ditutup. Dapat juga dibiarkan terbuka untuk kemungkinan prioritas ulang jika lebih banyak pengguna terkena dampak.
  • kotak es
    • Kami tidak memiliki waktu untuk menangani masalah ini atau waktu untuk menerima kontribusi. Kami akan menutup masalah ini untuk menunjukkan bahwa tidak ada yang sedang mengerjakannya, tetapi akan terus memantau validitasnya dari waktu ke waktu dan mengaktifkannya kembali jika ada cukup orang yang terpengaruh dan jika kami memiliki resource untuk menanganinya. Seperti biasa, jangan ragu untuk memberi komentar atau menambahkan reaksi terhadap masalah ini bahkan saat ditutup.

Label tim

Untuk masalah baru, kami tidak lagi menggunakan label category: * dan menggantinya dengan label tim.

Lihat daftar lengkap label di sini.