Django uses Trac for managing the work on the code base. Trac is a community-tended garden of the bugs people have found and the features people would like to see added. As in any garden, sometimes there are weeds to be pulled and sometimes there are flowers and vegetables that need picking. We need your help to sort out one from the other, and in the end we all benefit together.
Like all gardens, we can aspire to perfection but in reality there’s no such thing. Even in the most pristine garden there are still snails and insects. In a community garden there are also helpful people who – with the best of intentions – fertilize the weeds and poison the roses. It’s the job of the community as a whole to self-manage, keep the problems to a minimum, and educate those coming into the community so that they can become valuable contributing members.
Similarly, while we aim for Trac to be a perfect representation of the state of Django’s progress, we acknowledge that this simply will not happen. By distributing the load of Trac maintenance to the community, we accept that there will be mistakes. Trac is “mostly accurate”, and we give allowances for the fact that sometimes it will be wrong. That’s okay. We’re perfectionists with deadlines.
We rely on the community to keep participating, keep tickets as accurate as possible, and raise issues for discussion on our mailing lists when there is confusion or disagreement.
Django is a community project, and every contribution helps. We can’t do this without you!
Sayangnyam tidak semua laporan kesalahan dan permintaan fitur di pelacak tiket menyediakan semua rincian dibutuhkan. Angka dari tiket mempunyai tambalan, tetapi tambalan tersebut tidak memenuhi semua persyaratan dari tambalan baik.
One way to help out is to triage tickets that have been created by other users. The core team and several community members work on this regularly, but more help is always appreciated.
Most of the workflow is based around the concept of a ticket’s triage stages. Each stage describes where in its lifetime a given ticket is at any time. Along with a handful of flags, this attribute easily tells us what and who each ticket is waiting on.
Sejak gambar berharga seribu kata, mari kita mulai disana:
Kami telah mendapat dua peran pada diagram ini:
Sebagai contoh, disini kita melihat daur hidup dari sebuah tiket rata-rata:
Alice membuat sebuah tiket, dan mengunggah sebuah tambalan tidak lengkap (tidak ada pengujian, penerapan tidak benar).
Bob meninjau tambalan, menandainya “Diterima”, “butuh pengujian”, dan “tambalan butuh perbaikan”, dan meninggalkan komentar mengatakan ke Alice bagaimana tambalan dapat diperbaiki.
Alice memperbaharui tambalan, menambahkan percobaan (tetapi tidak merubah penerapan). Dia memindahkan dua bendera.
Charlie meninjau tambalan dan menyetel kembali bendera “tambalan membutuhkan perbaikan” dengan komentar lain tentang memperbaiki penerapan.
Alice memperbaharui tambalan, memperbaiki penerapan. Dia memindahkan bendera “tambalan butuh diperbaiki”.
Daisy meninjau tambalan, dan menandai RFC nya.
Jacob, pengembang inti, meninjau tambalan RFC, memberlakukannya ke pemeriksaannya, dan menyerahkannya.
Beberapa tiket membutuhkan sedikit umpan balik daripada ini, tapi kembali lagi beberapa tiket membutuhkan lebih banyak.
Dibawah ini kami menggambarkan dalam lebih rinci beragam tingkatan dimana sebuah tiket mungkin mengalir selama siklus hidupnya.
Tiket belum ditinjau oleh seorangpun yang merasa berkualitas untuk membuat keputusan tentang apakah tiket mengandung masalah sah, fitur yang berjalan terus, atau mungkin menutup untuk beragam alasan.
Kawasan abu-abu besar! Arti mutlak dari “diterima” adalah bahwa masalah digambarkan dalam tiket adalah sah dan dalam beberapa tingkatan sedang dikerjakan. Diluar itu ada beberapa pertimbangan:
Diterima + Tidak ada Bendera
Tiket sah, tetapi tidak seorangpun mengajukan sebuah tambalan untuknya. Sering ini berarti anda dapat dengan aman memulai menulis tambalan untukn itu. Ini umumnya lebih benar untuk kasus dari kesalahan diterima daripada fitur diterima. Sebuah tiket untuk sebuah kesalahan yang telah diterima berarti bahwa masalah telah diperiksa oleh setidaknya satu penyortir sebagai kesalahan sah - dan harus diperbaiki jika memungkinkan. Sebuah fitur baru diterima hanya berarti bahwa satu penyortir berpikir akan bagus jika punya, tetapi ini sendiri tidak mewakili sebuah pandangan pemufakatan atau berarti dengan kepastian apapun yang sebuah tambalan akan diterima untuk fitur tersebut. Cari lebih umpan balik sebelum menulis tambalan tambahan jika anda ragu.
Diterima + Ada Tambalan
Tiket menunggu untuk orang untuk meninjau tambalan dipasok. Ini berarti mengunduh tambalan dan mencobanya, memeriksa bahwa itu mengandung percobaan dan dokumen, menjalankan deretan percobaan dengan tambalan disertakan, dan meninggalkan umpan balik pada tiket.
Diterima + Ada Tambalan + Dibutuhkan ...
Ini berarti tiket telah ditinjau, dan telah ditemukan untuk pekerjaan lebih lanjut. “Butuh Percobaan” dan “Butuh dokumentasi” adalah penjelasan-sendiri. “Butuh perbaikan tambalan” akan umumnya ditemani oleh komentar pada tiket menjelaskan apa yang dibutuhkan untuk memperbaiki kode.
Tiket telah ditinjau oleh anggota dari perkumpulan lain daripada orang yang memasok tambalan dan cocok semua persyaratan untuk tambalan siap-penyerahan. Seorang penyerah sekarang butuh untuk memberikan tambalan tinjauan akhir sebelum diserahkan. Lihat New contributors’ FAQ untuk “Tiket saya telah di dalam RFC selamanya! Apa yang harus saya lakukan?”
Tahapan ini tidak ditampilkan pada diagram. Itu hanya digunakan oleh pengembang inti untuk tetap melacak dari ide tingkat-tinggi atau permintaan fitur jangka panjang.
Tiket ini tidak umum dan keseluruhan kurang berguna sejak mereka tidak menggambarkan masalah nyata ditindaklanjuti. Mereka meningkatkan permintaan bahwa kami mungkin mempertimbangkan menambahkan suatu waktu ke kerangka jika sebuah tambalan sempurna diajukan. Mereka bukan prioritas tinggi.
Sejumlah bendera, muncul sebagai kotak centang di Trac, dapat di setel di tiket:
INi berarti tiket mempunyai sebuah patch terhubung. Ini akan ditinjau kembali untuk melihat jika tambalan ini “baik”.
Tiga bidang berikut (Butuh dokumentasi, Butuh percobaan, Tambalan butuh perbaikan) berlaku jika sebuah tambalan telah dipasok.
Bendera ini digunakan untuk tiket dengan tambalan yang butuh dokumentasi terkait. Dokumentasi lengkap dari fitur adalah prasyarat sebelum kami dapat memerika mereka ke dalam basiskode.
Ini menandai tambalan yang membutuhkan unit percobaan terkait. Kembali, ini adalah bagian diwajibkan dari tambalan sah.
Bendera ini berarti bahwa meskipun tiket mempunyai tambalan, itu tidak siap untuk pendaftaran. Ini daat berarti tambalan tidak lagi berlaku, ada sebuah cacat dalam penerapan, atau bahwa kode tidak memenuhi standar kami.
Tiket yang akan membutuhkan kecil, mudah, tambalan.
Tiket harus dikelompokkan berdasarkan jenis diantara:
Untuk menambahkan sesuatu baru.
Untuk ketika hal yang ada rusak atau tidak berperilaku seperti yang diharapkan.
Untuk ketika tidak ada yang rusak tetapi sesuatu dapat dibuat lebih jelas, lebih baik, lebih cepat, lebih kuat.
Tiket harus dikelompokkan kedalam komponen menandakan milik kawasan mana dari basiskode Django. Ini membuat tiket lebih baik tersusun dan lebih mudah ditemukan.
The severity attribute is used to identify blockers, that is, issues which should get fixed before releasing the next version of Django. Typically those issues are bugs causing regressions from earlier versions or potentially causing severe data losses. This attribute is quite rarely used and the vast majority of tickets have a severity of “Normal”.
Itu dimungkinkan menggunakan atribut versi untuk menandakan versi mana kesalahan dilaporkan telah dicirikan.
Bendera ini digunakan untuk tiket yang terkait ke Antarmuka Pengguna dan pertanyaan Pengalaman pengguna. Sebagai contoh, bendera ini akan sesuai untuk pengguna-menghadapi fitur dalam formulir atau antarmuka admin.
Anda mungkin menambahkan nama pengguna atau alamt surel ke bidang ini untuk diberitahu ketika bantuan baru dibuat ke tiket.
Dengan bidang ini anda memungkinkan menandakan sebuah tiket dengan banyak kata kunci. Ini dapat berguna, sebagai contoh, untuk mengelompokkan beberapa tiket dari tema sama. Kata kunci dapat juga dipisahkan dengan koma atau spasi. Kata kunci pencarian mencari deretan karakter dimanapun dalam kata kunci. Sebagai contoh, mengklik pada tiket dengan katakunci “form: akan menghasilkan tiket mirip ditandai dengan kata kunci mengandung deretan karakter seperti “formset”, “modelformset”, dan “ManagementForm”.
Ketika sebuah tiket telah melengkapi daur hidupnya, saatnya untuk itu ditutup. Menutup sebuah tiket adalah tanggung jawab besar, meskipun. Anda harus memastikan bahwa masalah benar-benar terselesaikan, dan anda butuh mengingat bahwa pelapor dari tiket mungkin tidak senang tiket mereka ditutup (meskipun sudah diperbaiki, tentunya). Jika anda tidak yakin tentang menutup sebuah tiket, ebih baik tinggalkan komentar dengan pemikiran anda.
Jika anda menutup sebuah tiket, anda harus selalu memastikan berikut:
Pastikan bahwa masalah terselesaikan.
Tinggalkan komentar menjelaskan keputusan untuk menutup tiket.
JIka ada cara mereka dapat memperbaiki tiket untuk membukanya, biarkan mereka mengetahui.
Jika tiket ganda, acukan tiket asli. Juga periksa acuan tiket tertutup dengan meninggalkan komentar dalam satu yang asli – ini mengizinkan untuk mengakses lebih informasi terkait tentang kesalahan dilaporkan atau fitur diminta.
Sopanlah Tidak seorangpun suka tiket milik mereka tutup. Itu dapat mengecewakan atau bahkan mengecilkan. Jalan terbaik untuk menghindari merubah orang dari membantu ke Django adalah menjadi sopan dan ramah dan untuk menawarkan saran untuk bagaimana mereka dapat memperbaiki tiket ini dan tiket lainnya di masa depan.
Sebuah tiket dapat diselesaikan dalam sejumlah jalan:
Digunakan oleh pengembang inti sekali sebuah tambalan telah di gulingkan ke dalam Django dan masalah diperbaiki.
DIgunakan jika tiket ditemukan tidak benar. Ini berarti bahwa masalah dalam tiket sebenarnya hasil dari kesalahan pengguna, atau menggambarkan sebuah masalah dengan sesuatu selain daripada Django, atau bukan laporan kesalahan atau permintaan kesalahan (sebagai contoh, beberapa pengguna baru mengajukan permintaan dukungan sebagai tiket).
Digunakan ketika pengembang inti memutuskan bahwa permintaan ini tidak sesuai untuk pertimbangan dalam Django. Ini biasanya dipilih setelah obrolan dalam daftar penyuratan django-developers. Merasa bebas untuk mulai atau bergabung daam obrolan dari tiket “wontfix” pada daftar penyuratan, tetapi mohon jangan membuka kembali tiket tertutup sebagai “wontfix” oleh core developer.
Digunakan ketika tiket lainnya menutuoi masalah sama. Dengan menutup tiket ganda, kami menjaga semua obrolan dalam satu tempat, yang membantu semua orang.
Digunakan ketika tiket tidak mengandung cukup rincian untuk mengulangi kesalahan asli.
Digunakan ketika tiket tidak mengandung cukup informasi untuk mengulangi masalah dilaporkan tetapi masih berpotensi sah. Tiket harus dibuka kembali ketika informasi lebih dipasok.
Jika anda percaya bahwa tiket yang telah ditutup dalam salah – karena anda masih mempunayi masalah sama, atau itu muncul ditempat lain, atau penyortir telah membuat sebauh kesalahan – silahkan buka kembali tiket dan sediakan informasi lebih lanjut. Kembali, mohon jangan dibuka kembali tiket yang telah ditandai sebagai “wontfix” oleh pengembang inti dan membawa masalah ke django-developers.
Pengolahan penyortiran adalah utamanya dikendalikan oleh anggota komunitas. Benar, SIAPAPUN dapat membantu.
Pengembang inti mungkin menyediakan umpan balik pada masalah yang mereka paham, atau membuat keputusan pada satu yang berlawanan, tetapi mereka tidak bertanggung jawab untuk penyortiran tiket secara umum.
Untuk ikut serta, mulai dengan membuat sebuah akun pada Trac. Jika anda mempunyai sebuah akun tetapi lupa sandi anda, anda dapat menyetel kembali menggunakan password reset page.
lalu, anda dapat membantu dengan:
Setel jenis dari tiket yang masih belum dikelompokkan.
Memeriksa tiket lama itu masih sah. Jika sebuah tiket tidak kelihatan aktifitas apapun dalam jangka lama, itu dimungkinkan bahwa masalah telah diperbaiki tetapi tiket belum ditutup.
Kenali gaya dan tema dalam tiket. Jika ada banyak laporan kesalahan tentang bagian tertentu dari Django, itu mungkin menandakan kami harus mempertimbangkan refaktorisasi bagian itu dari kode. Jika sebuah gaya muncul, anda harus menampilkannya untuk obrolan (mengacu tiket yang sesuai) pada django-developers.
Periksa jika tambalan diajukan oleh pengguna lain adalah benar. Jika mereka benar dan juga mengandung dokumentasi dan percobaan yang sesuai kemudian pindahkan mereka ke tahapan “Siap untuk Pendaftaran”. Jika mereka tidak benar lalu tinggalkan sebuah komentar untuk menjelaskan mengapa dan setel bendera sesuai (“Tambalan butuh perbaikan”, “Butuh percobaan” dll.).
Catatan
The Reports page contains links to many useful Trac queries, including several that are useful for triaging tickets and reviewing patches as suggested above.
Anda dapa juga menemukan lebih Saran untuk penyumbang baru.
However, we do ask the following of all general community members working in the ticket database:
Mohon jangan tutup tiket sebagai “wontfix.” Pengembang inti akan membuat penentuan akhir dari takdir sebuah tiket, biasanya setelah berunding dengan komunitas.
Mohon jangan mengenalkan tiket anda sendiri ke “Siap untuk Pendaftaran”. Anda mungkin menandai tiket orang lain yang anda telah tinjau sebagai “Siap untuk Pendaftaran”, tetapi anda harus mendapatkan minimal satu anggota komunitas lain untuk meninjau sebuah tambalan yang anda ajukan.
Mohon jangan membalikkan keputusan yang telah dibuat oleh pengembang inti. Jika anda tidak setuju dengan sebuah keputusan yang telah dibuat, silahkan tempatkan sebuah pesan ke django-developers.
Jika anda tidak yakin jika anda harus membuat sebuah perubahan, jangan membuat perubahan tetapi lebih baik tinggalkan sebuah komentar dengan perhatian anda pada tiket, atau tempatkan sebuah pesan ke django-developers. Tidak apa-apa untuk tidak yakin, tetapi masukan anda masih berharga.
Pemulihan adalah sebuah kesalahan yang hadir dalam beberapa versi terbaru dari Django tetapi tidak di versi lama. Sepotong informasi sangat membantu adalah penyerahan yang memperkenalkan pemulihan. Sepengetahuan penyerahan yang menyebabkan perubahan dalam kebiasaan membantu mencirikan jika perubahan disengaja atau jika itu efek samping tidak sengaja. Disini bagaimana anda dapat menentukan ini.
Begin by writing a regression test for Django’s test suite for the issue. For
example, we’ll pretend we’re debugging a regression in migrations. After you’ve
written the test and confirmed that it fails on the latest master, put it in a
separate file that you can run standalone. For our example, we’ll pretend we
created tests/migrations/test_regression.py
, which can be run with:
$ ./runtests.py migrations.test_regression
Selanjutnya, kami menandai titik saat ini dalam sejarah menjadi “buruk” sejak kegagalan percobaan:
$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y
Sekarang, kami butuh menemukan titi dalam sejarah git sebelum pemulihan diperkenalkan (yaitu sebuah titik dimana percobaan lulus). Gunakan sesuatu seperti git checkout HEAD~100
untuk memeriksa pembetulan awal (100 penyerahan awal, dalam kasus ini). Periksa jika percobaan gagal. Jika demikian, tandai titik itu sebagai “buruk” (git bisect bad
), lalu periksa pembetulan awal dan periksa kembali. Sekali anda menemukan pembetulan dimana percobaan anda lulus, tandai itu sebagai “bagus”:
$ git bisect good
Bisecting: X revisions left to test after this (roughly Y steps)
...
Now we’re ready for the fun part: using git bisect run
to automate the rest
of the process:
$ git bisect run python runtests.py migrations.test_regression
You should see git bisect
use a binary search to automatically checkout
revisions between the good and bad commits until it finds the first “bad”
commit where the test fails.
Now, report your results on the Trac ticket, and please include the regression test as an attachment. When someone writes a fix for the bug, they’ll already have your test as a starting point.
Agt 01, 2016