Panduan untuk Pengelola Bazel

Nightly · 9.1 · 9.0 · 8.7 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

Panduan ini ditujukan untuk pengelola project open source Bazel.

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

Tujuan halaman ini adalah:

  1. Menjadi sumber kebenaran pengelola untuk proses kontribusi project.
  2. Menetapkan ekspektasi antara kontributor komunitas dan pengelola project.

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

  • Proses Rilis: Mengelola proses rilis Bazel.
  • Tim Hijau: Mengembangkan ekosistem aturan dan alat yang sehat.
  • Pengembang Pengalaman Pengguna: Mendorong kontribusi eksternal, meninjau masalah dan permintaan pull, serta 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 dengan memilih salah satu template masalah dan masalah tersebut masuk ke kumpulan masalah terbuka yang belum ditinjau.
  2. Anggota rotasi subtim Pengalaman Pengembang (DevEx) meninjau masalah tersebut.
    1. Jika masalah bukan bug atau permintaan fitur, anggota DevEx biasanya akan menutup masalah tersebut dan mengalihkan pengguna ke StackOverflow dan bazel-discuss untuk mendapatkan visibilitas yang lebih tinggi pada pertanyaan tersebut.
    2. Jika masalah tersebut termasuk dalam 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 ada informasi yang kurang, 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 akan memutuskan apakah masalah tersebut memerlukan perhatian segera. Jika ya, mereka akan menetapkan label P0 prioritas dan pemilik dari daftar ketua tim.
  4. Anggota DevEx menetapkan label untriaged dan tepat satu label tim untuk perutean.
  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 masalahnya berprioritas rendah dan dapat dikerjakan oleh kontributor komunitas baru, anggota DevEx akan menetapkan label good first issue. Pada tahap ini, masalah tersebut masuk ke kumpulan masalah terbuka yang belum ditinjau.

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

Setelah masalah diselesaikan, masalah tersebut dapat ditutup.

Siklus Proses Permintaan Pull

  1. Pengguna membuat permintaan pull.
  2. Jika Anda adalah anggota tim Bazel dan mengirim PR ke area Anda sendiri, Anda bertanggung jawab untuk menetapkan label tim dan menemukan peninjau terbaik.
  3. Jika tidak, selama peninjauan harian, anggota DevEx akan menetapkan satu label tim dan ketua teknis (TL) tim untuk perutean.
    1. TL dapat menetapkan orang lain untuk meninjau PR.
  4. Peninjau yang ditetapkan akan meninjau PR dan bekerja sama dengan penulis hingga PR 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 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 akan digabungkan dan diekspor kembali ke GitHub.
  7. Saat commit digabungkan ke master, GitHub akan otomatis menutup PR.

Tim saya memiliki label. Apa yang harus saya lakukan?

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

Masalah

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

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

Permintaan Pull

  1. Filter daftar permintaan pull menurut label tim Anda.
  2. Tinjau permintaan pull terbuka.
    1. Opsional: Jika Anda ditetapkan untuk peninjauan, tetapi tidak sesuai untuk peninjauan tersebut, tetapkan kembali peninjau yang sesuai untuk melakukan peninjauan kode.
  3. Bekerja sama dengan pembuat permintaan pull untuk menyelesaikan peninjauan kode.
  4. Setujui PR.
  5. Pastikan semua pengujian berhasil.
  6. Impor patch ke sistem kontrol versi internal dan jalankan presubmit internal.
  7. Kirim patch internal. Jika patch berhasil dikirim dan diekspor, PR akan otomatis ditutup oleh GitHub.

Prioritas

Definisi prioritas berikut akan digunakan oleh pengelola untuk meninjau masalah.

  • P0 - Fungsi utama yang rusak dan menyebabkan rilis Bazel (minus kandidat rilis) tidak dapat digunakan, atau layanan yang tidak berfungsi dan berdampak parah pada pengembangan project Bazel. Hal ini mencakup regresi yang diperkenalkan dalam rilis baru yang memblokir sejumlah besar pengguna, atau perubahan yang tidak kompatibel dan tidak mematuhi kebijakan Perubahan yang Tidak Kompatibel. Tidak ada solusi praktis.
  • P1 - Cacat atau fitur penting 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. Sangat diminati dan direncanakan dalam roadmap kuartal saat ini.
  • P2 - Cacat atau fitur yang harus ditangani, tetapi saat ini kami tidak mengerjakannya. Masalah live sedang dalam versi Bazel yang dirilis dan tidak nyaman bagi pengguna yang perlu ditangani dalam rilis mendatang dan/atau ada solusi yang mudah.
  • P3 - Perbaikan bug kecil atau peningkatan yang diinginkan dengan dampak kecil. Tidak diprioritaskan ke dalam roadmap Bazel atau rilis yang akan datang, tetapi kontribusi komunitas dianjurkan.
  • P4 - Cacat berprioritas rendah atau permintaan fitur yang kemungkinan tidak akan ditutup. Dapat juga dibiarkan terbuka untuk kemungkinan memprioritaskan ulang jika lebih banyak pengguna yang terpengaruh.
  • ice-box
    • Masalah yang saat ini tidak dapat kami tangani atau tidak ada waktu untuk menerima kontribusi. Kami akan menutup masalah ini untuk menunjukkan bahwa tidak ada yang mengerjakannya, tetapi akan terus memantau validitasnya dari waktu ke waktu dan mengaktifkannya kembali jika ada cukup banyak orang yang terpengaruh dan jika kami memiliki resource untuk menanganinya. Seperti biasa, Anda dapat memberikan komentar atau menambahkan reaksi terhadap masalah ini meskipun masalah tersebut ditutup.

Label tim

Untuk masalah baru, kami menghentikan penggunaan label category: * dan menggantinya dengan label tim.

Lihat daftar lengkap label di sini.