Panduan untuk Pengelola Bazel

Laporkan masalah Lihat sumber

Ini adalah panduan bagi pengelola project open source Bazel.

Jika Anda ingin memberikan kontribusi 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 proyek.

Grup kontributor inti Bazel telah mendedikasikan subtim untuk mengelola aspek project open source. Di antaranya:

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

Rilis

Continuous Integration

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

Siklus Proses Masalah

  1. Pengguna membuat masalah dengan memilih salah satu template masalah dan memasuki kumpulan masalah terbuka yang belum ditinjau.
  2. Seorang anggota dalam rotasi subtim Developer Experience (DevEx) meninjau masalah.
    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 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 masalah tidak jelas atau memiliki informasi yang tidak lengkap, anggota DevEx akan menetapkan kembali masalah tersebut kepada pengguna untuk meminta informasi selengkapnya sebelum melanjutkan. Hal ini biasanya terjadi saat pengguna tidak memilih template masalah yang tepat {: .external} atau memberikan informasi yang tidak lengkap.
  3. Setelah meninjau masalah, anggota DevEx memutuskan apakah masalah tersebut memerlukan perhatian segera. Jika ya, mereka akan menetapkan label prioritas P0 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 tersebut 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 terselesaikan.

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

Jika masalah telah 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 pengulas terbaik.
  3. Jika tidak, selama triase harian, anggota DevEx akan menetapkan satu label tim dan pimpinan teknis (TL) tim untuk memilih rute.
    1. TL dapat secara opsional menugasi orang lain untuk meninjau PR.
  4. Peninjau yang ditugaskan meninjau Humas dan bekerja sama dengan penulis sampai 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 mengapa kita tidak menggabungkan PR secara langsung.
  6. Jika commit yang diimpor lulus semua pengujian internal, commit akan diciutkan dan diekspor kembali ke GitHub.
  7. Saat commit digabungkan ke master, GitHub akan otomatis menutup PR.

Tim saya memiliki label. Apa yang sebaiknya saya lakukan?

Subtim perlu melakukan triase semua masalah di 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 itu P0. Prioritaskan ulang jika perlu.
    2. Setiap masalah harus memiliki tepat satu label prioritas. Jika masalahnya adalah P0 atau P1, kami berasumsi bahwa masalah tersebut telah ditangani secara aktif.
  4. Hapus label untriaged.

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

Permintaan Pull

  1. Filter daftar permintaan pull menurut label tim Anda.
  2. Tinjau permintaan pull yang terbuka.
    1. Opsional: Jika Anda ditetapkan untuk melakukan peninjauan, tetapi tidak sesuai untuk melakukannya, tetapkan kembali peninjau yang sesuai untuk melakukan peninjauan kode.
  3. Bekerja samalah dengan pembuat permintaan pull untuk menyelesaikan peninjauan kode.
  4. Menyetujui 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, GitHub akan otomatis ditutup.

Prioritas

Definisi prioritas berikut akan digunakan oleh pengelola untuk memilah masalah.

  • P0 - Fungsi utama yang rusak yang menyebabkan rilis Bazel (dikurangi kandidat rilis) menjadi tidak dapat digunakan, atau layanan berhenti 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 yang tidak mematuhi kebijakan Perubahan yang Dapat Menyebabkan Gangguan. Tidak ada solusi praktis.
  • P1 - Kerusakan atau fitur kritis yang harus diatasi dalam rilis berikutnya, atau masalah serius yang memengaruhi banyak pengguna (termasuk pengembangan project Bazel), tetapi ada solusi praktisnya. Biasanya tidak memerlukan tindakan langsung. Dengan permintaan yang tinggi dan sudah direncanakan dalam roadmap kuartal saat ini.
  • P2 - Kerusakan atau fitur yang harus diatasi tetapi saat ini belum kami tangani. Memoderasi masalah langsung pada versi Bazel yang telah dirilis dan merepotkan pengguna yang perlu ditangani dalam rilis mendatang dan/atau sudah ada solusi yang mudah.
  • P3 - Perbaikan bug kecil atau peningkatan kualitas yang diinginkan dengan dampak kecil. Tidak diprioritaskan pada roadmap Bazel atau rilis dalam waktu dekat, tetapi kontribusi komunitas akan dianjurkan.
  • P4 - Kerusakan prioritas rendah atau permintaan fitur yang tidak mungkin ditutup. Dapat juga dibiarkan terbuka untuk potensi pengaturan ulang prioritas jika ada lebih banyak pengguna yang terdampak.
  • kotak es
    • Masalah yang saat ini tidak dapat kami tangani atau menerima kontribusi. Kami akan menutup masalah ini untuk menunjukkan bahwa tidak ada yang sedang menanganinya, tetapi kami akan terus memantau validitasnya dari waktu ke waktu dan mengaktifkannya kembali jika ada cukup banyak orang yang terdampak dan jika kami kebetulan memiliki sumber daya untuk menanganinya. Seperti biasa, jangan ragu untuk mengomentari 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.