Panduan untuk Pengelola Bazel

Laporkan masalah Lihat sumber {/18/}{/1/}

Ini adalah panduan bagi para pengelola proyek open source Bazel.

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

Tujuan halaman ini adalah untuk:

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

Grup kontributor inti Bazel memiliki subtim khusus untuk mengelola aspek project open source. Tugas tersebut adalah:

  • Proses Rilis: Mengelola proses rilis Bazel.
  • Green Team: Tumbuhkan ekosistem aturan dan alat yang sehat.
  • Developer Experience Developer: Dorong kontribusi eksternal, tinjau masalah dan permintaan pull, serta buat alur kerja pengembangan kami lebih terbuka.

Rilis

Continuous Integration

Baca panduan tim Green tentang infrastruktur CI Bazel di repositori bazelbuild/continuous-integration.

Siklus Proses Masalah

  1. Pengguna membuat masalah dengan memilih salah satu template masalah dan memasukkan kumpulan masalah terbuka yang belum ditinjau.
  2. Seorang anggota rotasi subtim Developer Experience (DevEx) meninjau masalah ini.
    1. Jika masalahnya bukan bug atau permintaan fitur, anggota DevEx biasanya akan menutup masalah tersebut dan mengalihkan pengguna ke StackOverflow dan bazel-discuss untuk visibilitas yang lebih tinggi pada pertanyaan.
    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 masalahnya tidak jelas atau informasinya tidak lengkap, anggota DevEx akan menetapkan kembali masalah tersebut kepada pengguna untuk meminta informasi lebih lanjut sebelum melanjutkan. Hal ini biasanya terjadi jika pengguna tidak memilih template masalah {: .external} yang tepat atau memberikan informasi yang tidak lengkap.
  3. Setelah meninjau masalah tersebut, anggota DevEx memutuskan apakah masalah tersebut memerlukan perhatian segera. Jika ya, mereka akan menetapkan label P0 priority dan pemilik dari daftar pemimpin tim.
  4. Anggota DevEx menetapkan label untriaged dan satu label tim untuk pemilihan rute.
  5. Anggota DevEx juga menetapkan 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 memiliki prioritas rendah dan dapat dikerjakan oleh kontributor komunitas baru, anggota DevEx akan menetapkan label good first issue. Pada tahap ini, masalah akan masuk ke kumpulan masalah terbuka yang tidak teratasi.

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

Masalah dapat ditutup setelah diselesaikan.

Siklus Proses Permintaan Pull

  1. Pengguna membuat permintaan pull.
  2. Jika Anda adalah anggota tim Bazel dan mengirim PR untuk wilayah 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 (TL) tim untuk pemilihan rute.
    1. TL dapat menunjuk orang lain untuk meninjau PR secara opsional.
  4. Peninjau yang ditugaskan akan meninjau PR dan bekerja sama dengan penulisnya hingga disetujui atau dibatalkan.
  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, kita perlu menguji semua commit PR terhadap rangkaian pengujian internal. Inilah alasan mengapa kami tidak menggabungkan PR secara langsung.
  6. Jika commit yang diimpor lulus semua pengujian internal, commit akan digabungkan dan diekspor kembali ke GitHub.
  7. Saat commit bergabung ke master, GitHub otomatis menutup PR.

Tim saya memiliki label. Apa yang harus saya lakukan?

Subtim perlu menyortir 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 sudah diprioritaskan oleh subtim DevEx jika berupa P0. Prioritaskan ulang jika perlu.
    2. Setiap masalah harus memiliki tepat satu label prioritas. Jika masalah adalah P0 atau P1, kami berasumsi bahwa masalah tersebut sedang dikerjakan secara aktif.
  4. Hapus label untriaged.

Perhatikan bahwa Anda harus berada dalam organisasi bazelbuild agar dapat menambahkan atau menghapus label.

Permintaan Pull

  1. Filter daftar permintaan pull menurut label tim Anda.
  2. Meninjau permintaan pull terbuka.
    1. Opsional: Jika Anda ditugaskan untuk peninjauan tetapi tidak cocok untuk peninjauan tersebut, tetapkan kembali peninjau yang sesuai untuk melakukan peninjauan kode.
  3. Bekerja samalah dengan pembuat permintaan pull untuk menyelesaikan peninjauan kode.
  4. Menyetujui Humas.
  5. Pastikan semua pengujian lulus.
  6. Impor patch ke sistem kontrol versi internal dan jalankan pra-pengiriman internal.
  7. Kirim patch internal. Jika patch berhasil dikirim dan diekspor, PR akan otomatis ditutup oleh GitHub.

Prioritas

Definisi untuk prioritas berikut akan digunakan oleh pengelola untuk memprioritaskan masalah.

  • P0 - Fungsi besar yang rusak yang menyebabkan rilis Bazel (kecuali kandidat rilis) tidak dapat digunakan, atau layanan yang telah dihentikan yang sangat memengaruhi pengembangan project Bazel. Hal ini mencakup regresi yang diperkenalkan dalam rilis baru yang memblokir sejumlah besar pengguna, atau perubahan yang dapat menyebabkan gangguan yang tidak kompatibel dan tidak mematuhi kebijakan Perubahan yang Dapat Menyebabkan. Tidak ada solusi praktis.
  • P1 - Cacat atau fitur kritis atau fitur yang harus ditangani dalam rilis berikutnya, atau masalah serius yang memengaruhi banyak pengguna (termasuk pengembangan project Bazel), tetapi ada solusi praktis. Biasanya tidak memerlukan tindakan segera. Dalam permintaan yang tinggi dan terencana dalam roadmap kuartal saat ini.
  • P2 - Kerusakan atau fitur yang harus ditangani, tetapi saat ini tidak kami tangani. Masalah live sedang dalam versi Bazel yang dirilis dan merepotkan pengguna dan perlu ditangani dalam rilis mendatang dan/atau ada solusi yang mudah.
  • P3 - Peningkatan atau peningkatan bug kecil yang diinginkan dengan dampak kecil. Tidak diprioritaskan dalam roadmap Bazel atau rilis dalam waktu dekat, tetapi kontribusi komunitas dianjurkan.
  • P4 - Kerusakan prioritas rendah atau permintaan fitur yang kemungkinan tidak akan ditutup. Juga dapat tetap terbuka untuk kemungkinan pengaturan ulang prioritas jika ada lebih banyak pengguna yang terdampak.
  • kotak es
    • Masalah yang saat ini tidak ada waktu untuk ditangani atau tidak ada waktu untuk menerima kontribusi. Kami akan menutup masalah ini untuk menunjukkan bahwa tidak ada yang mengerjakannya, tetapi kami akan terus memantau validitasnya dari waktu ke waktu dan memulihkannya jika ada cukup banyak orang yang terdampak dan jika kami memiliki sumber daya untuk menanganinya. Seperti biasa, jangan ragu untuk berkomentar atau menambahkan reaksi terhadap masalah ini bahkan saat Anda sudah menyelesaikan tugas ini.

Label tim

Untuk masalah baru, kami menghentikan penggunaan label category: * dan digantikan oleh label tim.

Lihat daftar lengkap label di sini.