Bagaimana Bug dikategorikan dan apa siklus hidup bug?


12

Bagaimana bug di ubuntu dikategorikan dan apa siklus hidup bug?

Juga, "Apa yang dimaksud dengan 'Status' setiap bug, dan bagaimana cara menentukannya"

Jawaban:


18

Semua bug di Ubuntu memiliki siklus hidup. Selain itu, mereka masing-masing memiliki "Status" yang membantu menjelaskan apa siklus hidupnya. Di Ubuntu, setiap bug saat siklus hidupnya berlanjut memiliki berbagai status yang ditetapkan padanya.

Walaupun ini semua didokumentasikan dengan sangat luar biasa dalam Panduan Triage , saya akan (untuk saat ini, karena saya tidak punya banyak waktu untuk menulis proses ini dalam bentuk teks, tetapi nanti saya akan) memposting "Diagram Alir" yang disediakan oleh Regu Bug untuk ini ( klik di sini untuk sumber diagram alur ). Setiap status (sementara itu) dapat dijelaskan dalam Dokumentasi Bugs / Status BugSquad , tetapi saya juga mendokumentasikannya di sini.

(Perhatikan bahwa informasi di bawah ini mungkin sudah ketinggalan zaman dengan dokumentasi di wiki, Anda harus merujuk ke wiki untuk informasi terbaru).


Berikut ini adalah deskripsi setiap indikator status pada bug:

  • Baru:
    • Bug dikirimkan dengan status ini
    • Mereka terkadang kekurangan informasi dan
    • Semuanya harus tidak terluka
  • Tidak lengkap:
    • Jika Anda harus mengajukan pertanyaan kepada reporter, atur bug ke Tidak Lengkap
    • Minta pengirim untuk memberikan informasi yang diperlukan dalam komentar, dan pastikan Anda berlangganan laporan bug sehingga Anda akan mendapat pembaruan bug tersebut melalui email.
    • Beberapa bug tidak pernah ditanggapi oleh pengirim (juga disebut "poster asli", atau "OP"). Bug ini akan kedaluwarsa secara otomatis oleh Launchpad dalam 60 hari, dihitung sejak hari itu ditetapkan tidak lengkap. Tidak perlu menindakinya (dan, sebenarnya, mengubah bug akan memulai kembali periode kedaluwarsa). Perhatikan bahwa ini berlaku untuk proyek Ubuntu (yaitu, tugas-tugas bug yang memiliki "(Ubuntu)" di namanya). Proyek lain mungkin, atau mungkin tidak, memiliki set kedaluwarsa bug tidak lengkap otomatis.
    • Jika ada orang, termasuk Anda, mengomentari bug, jam kedaluwarsa 60 hari diatur ulang.
  • Pendapat:
    • Status 'opini' berarti ada perbedaan pendapat di sekitar bug tertentu dan orang bebas untuk melanjutkan diskusi, tetapi pengelola proyek atau paket perlu pindah ke pekerjaan lain dan sedang mempertimbangkan masalah ditutup. Idenya adalah bahwa bug dapat ditandai ditutup, sehingga pengembang tidak membuang waktu untuk mereka, tetapi diskusi masih bisa berlangsung.
    • 'Pendapat' status ini dianggap sebagai eksperimen, dan akan dimonitor secara ketat.
  • Tidak valid:
    • Status ini harus digunakan ketika laporan bug tidak mengandung informasi yang memadai untuk menentukan apakah itu bug atau tidak walaupun itu diselesaikan untuk pelapor.
    • Ini juga harus digunakan jika masalah yang dilaporkan bukan bug sama sekali, tetapi sebagai contoh kesalahan pengguna
    • Itu harus digunakan secara konservatif sebagai bug yang ditandai sebagai Tidak Valid tidak lagi muncul dalam pencarian default
    • Pastikan untuk memeriksa tiga kali bug sebelum Anda membatalkannya
  • Kedaluwarsa:
    • Status ini mirip dengan Tidak Valid, tetapi dimaksudkan khusus untuk bug yang terlalu lama tidak lengkap. (Lihat di atas.)
    • Status ini hanya dapat diatur dengan menggunakan launchpadlib atau antarmuka email.
    • Seperti bug yang tidak valid, bug yang kadaluarsa tidak muncul dalam pencarian default.
  • Dikonfirmasi :
    • Reporter lain telah mengalami bug yang sama, ini bisa datang dalam bentuk duplikat bug atau komentar bug
    • Bug yang dikonfirmasi membutuhkan konfirmasi dari orang lain selain dari pelapor asli
    • Ini membantu memastikan bahwa bug tersebut berlaku untuk Ubuntu secara umum, dan bukan masalah dengan sistem reporter, oleh karena itu ...
    • Tolong jangan konfirmasi bug Anda sendiri!
  • Triaged:
    • Anggota UbuntuBugControl percaya bahwa laporan tersebut menjelaskan bug asli dengan cukup detail sehingga pengembang dapat mulai memperbaiki. (lihat juga tip di bawah)
    • Gunakan ini ketika Anda yakin bahwa itu harus dilihat oleh pengembang dan memiliki informasi yang cukup
    • Meskipun bukan keharusan, status tugas Ubuntu bug akan di Triaged sebelum penerusan upstream terjadi
    • Dengan bug tentang linux Triaged berarti bug telah diuji dengan kernel arus utama upstream
  • Sedang berlangsung:
    • Jika Anda sedang memperbaiki bug, aturlah ke In Progress agar orang-orang tahu apa yang terjadi
    • Dalam Kemajuan, bug harus diberikan kepada orang yang mengerjakannya
  • Memperbaiki Komitmen:
    • Tugas bug Ubuntu: perubahannya sedang menunggu dan akan segera diunggah (seperti PENDINGUPLOAD di Bugzilla)
    • Fix Committed juga digunakan ketika paket yang diperbarui ada di repositori -proposed yaitu hardy-diusulkan
    • Fix Committed tidak untuk digunakan ketika patch dilampirkan ke bug
    • Tugas bug upstream: perbaikannya ada di CVS / SVN / bzr atau dilakukan di beberapa tempat
  • Perbaiki Dirilis:
    • Tugas bug Ubuntu: perbaikan diunggah ke repositori Ubuntu resmi
    • NB Ini tidak termasuk-diusulkan yaitu hardy-diusulkan
    • Tolong jangan ragu untuk menambahkan changelog sebagai komentar, jadi orang tahu di mana versi paket bug diperbaiki
    • Jika bug diperbaiki dalam rilis pengembangan saat ini, itu diperbaiki. Jika bug juga perlu diperbaiki dalam rilis yang stabil, gunakan tautan "Target to release" untuk menominasikannya untuk rilis itu.
    • Tugas bug upstream: tarball rilis diumumkan dan tersedia untuk umum
  • Tidak akan memperbaiki:
    • Status ini terkadang digunakan ketika perbaikan bug terlalu kontroversial
    • Ini paling sering digunakan untuk bug dengan target rilis yang tidak akan diperbaiki dalam rilis tertentu tetapi dapat diperbaiki nanti
    • Ini juga dapat digunakan untuk permintaan fitur yang tidak ingin diterapkan oleh pengembang

(pemformatan akan sedikit berbeda dari wiki karena pemformatan di sini lebih terbatas)


Pertanyaan dan Jawaban Terkait:
Nilai Penting: Bagaimana Nilai Penting Bug Ubuntu Diputuskan


Diagram alir dihapus - kita perlu membangunnya kembali pada titik tertentu, saya rasa ...
Thomas Ward
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.