[ English | Deutsch | français | русский | English (United Kingdom) | Indonesia | 한국어 (대한민국) ]

OpenStack-Ansible Bug Handling

Pelaporan Bug

Bug harus diarsipkan di OpenStack-Ansible Launchpad project.

Saat mengirimkan bug, atau mengerjakan bug, pastikan kriteria berikut terpenuhi:

  • Deskripsi dengan jelas menyatakan atau menjelaskan masalah asli atau akar penyebab masalah.

  • Deskripsi dengan jelas menyatakan hasil yang diharapkan dari tindakan pengguna.

  • Sertakan informasi historis tentang bagaimana masalah itu diidentifikasi.

  • Semua log atau konfigurasi pengguna yang relevan disertakan, baik secara langsung atau melalui pastebin.

  • Jika masalahnya adalah bug yang harus diperbaiki di cabang selain master, harap perhatikan cabang terkait dalam masalah luncur.

  • Informasi yang disediakan harus benar-benar lengkap (self-contained). Akses eksternal ke layanan / situs web tidak diperlukan.

  • Langkah-langkah untuk mereproduksi masalah jika memungkinkan.

Bug Tags

Jika kebutuhan yang dilaporkan diperbaiki di cabang selain master, tambahkan tag '<release>-backport-potential' (misal liberty-backport-potential). Ada tag yang telah ditentukan yang akan otomatis selesai.

Status

Silakan tinggalkan status dari suatu masalah sendirian sampai seseorang mengonfirmasi atau anggota dari tim bug melakukan triage (menetapkan derajat urgensi). Sambil menunggu masalah untuk dikonfirmasi atau diprioritaskan, status harus tetap sebagai New.

Importance

Hanya harus disentuh jika itu adalah masalah Blocker/Gating. Jika ya, setel ke High, dan hanya gunakan Critical jika Anda telah menemukan bug yang dapat menghapus seluruh infrastruktur. Begitu pentingnya telah diubah, status harus diubah menjadi Triaged oleh orang lain selain pencipta bug.

Proses triaging dijelaskan di bawah ini.

Bug triage

Apa itu bug triage

"Bug triage adalah proses di mana masalah pelacak disaring dan diprioritaskan. Triage harus membantu memastikan kami mengelola dengan tepat semua issues - bug yang dilaporkan serta peningkatan dan permintaan fitur." (Source: Moodle bug triage)

Bug yang dilaporkan perlu konfirmasi, prioritas, dan memastikan bug tidak basi. Jika Anda peduli tentang stabilitas OpenStack tetapi tidak ingin secara aktif mengembangkan peran dan buku pedoman yang digunakan dalam proyek OpenStack-Ansible, pertimbangkan untuk berkontribusi dalam bidang bug triage.

Silakan referensi Project Team Guide bugs reference_ untuk informasi tentang bug status/importance dan siklus hidup bug.

Tugas rapat triage bug

Jika deskripsi bug tidak lengkap, atau laporan kekurangan informasi yang diperlukan untuk mereproduksi masalah, minta reporter untuk memberikan informasi yang hilang, dan atur status bug ke Incomplete

Jika laporan bug berisi cukup informasi dan Anda dapat memperbanyaknya (atau terlihat valid), maka Anda harus mengatur statusnya Confirmed.

Jika bug memiliki implikasi keamanan, atur tanda keamanan (di bawah "This report is public" di kanan atas)

Jika bug mempengaruhi area tertentu yang dicakup oleh tag resmi, Anda harus mengatur tag. Misalnya, jika bug tersebut kemungkinan cukup mudah untuk dipecahkan, tambahkan tag low-hanging-fruit.

Rapat triage bug mungkin merupakan saat yang tepat bagi orang-orang dengan hak pengawas bug untuk juga memprioritaskan bug per kepentingan (di atas mengklasifikasikan mereka berdasarkan status).

Tugas membaca sekilas bug

Untuk membantu triaging bug, satu orang dari tim bug dapat aktif "bug skimming duty".

Q

Apa tujuan dari tugas pencarian sekilas kesalahan bug?

A

Tugas membaca sekilas bug mengurangi jumlah pekerjaan yang harus dihabiskan pengembang lain untuk melakukan analisis akar permasalahan (dan kemudian memperbaiki) laporan bug. Untuk ini, tutup laporan bug yang jelas tidak valid, konfirmasikan laporan bug yang jelas valid, ajukan pertanyaan jika ada yang tidak jelas.

Q

Apakah saya perlu membuktikan bahwa laporan bug valid/invalid sebelum saya dapat mengaturnya menjadi Confirmed/Invalid ?

A

Tidak. Terkadang bahkan tidak mungkin karena Anda tidak memiliki sumber daya. Melihat kode dan tes sering memungkinkan Anda untuk membuat dugaan yang berpendidikan (educated guess). Mengutip sumber Anda dalam komentar membantu diskusi.

Q

Apa status terbaik untuk menutup laporan bug jika masalahnya tidak dapat direproduksi?

A

Definitif Invalid. Status Incomplete adalah keadaan terbuka dan berarti bahwa lebih banyak informasi diperlukan.

Q

Bagaimana cara menangani laporan bug terbuka yang tidak lengkap terlalu lama?

A

Jika berada dalam kondisi ini selama lebih dari 30 hari dan tidak ada jawaban untuk pertanyaan terbuka yang diberikan, tutuplah Won't Fix.

Q

Bagaimana cara saya menangani ketergantungan pada bug lain atau fitur TBD di proyek lain? Sebagai contoh, saya dapat memperbaiki bug di OpenStack-Ansible tetapi saya membutuhkan fitur di Compute (nova) diimplementasikan sebelumnya.

A

Tinggalkan komentar di laporan bug OpenStack-Ansible yang menjelaskan ketergantungan ini dan tinggalkan tautan ke cetak biru atau laporan bug dari proyek lain yang Anda andalkan.

Q

Apakah saya harus memeriksa ulang laporan bug yang New dan memiliki penerima hak?

A

Biasanya tidak. Laporan bug ini memiliki kondisi yang tidak konsisten. Jika laporan bug memiliki orang yang ditunjuk, itu harus dalam Progress dan memiliki set penting.

Daftar periksa tugas skimming bug mingguan

  • Prioritaskan atau prioritaskan ulang OpenStack-Ansible confirmed bugs.

  • Pindahkan wishlist bugs tahun lalu ke Opinion/Wishlist untuk menghapus kekacauan. Anda dapat menggunakan pesan berikut:

    Bug wishlist ini telah dibuka setahun tanpa aktivitas apa pun. Saya memindahkan ini ke "Opini / Wishlist". Ini adalah antrian permintaan lama yang mudah diperoleh. Bug ini dapat dibuka kembali (disetel kembali ke "New") jika seseorang memutuskan untuk mengerjakan ini.

  • Pindahkan bug yang tidak dapat direproduksi ke keadaan tidak valid jika tidak dimodifikasi lebih dari sebulan.

  • Kirim email ke daftar openstack-discuss dengan list of bugs to triage selama seminggu. Bug baru yang ditandai sebagai Critical atau High harus diperlakukan sebagai prioritas.