Halaman ini terakhir diperbarui pada sJanuari 2017.

Pertama-tama, baca panduan pengembang baru.

Dasar Panduan Pengembang dan Gaya Coding

Sebagian besar hal berikut seharusnya panduan umum bagi siapa saja yang telah mengerjakan open source atau dalam lingkungan pemrograman komersial. Berikut ini berlaku terutama untuk cabang pengembangan utama i2p.i2p. Pedoman untuk cabang-cabang lain, plugin, dan aplikasi eksternal mungkin secara substansial berbeda; periksa dengan pengembang yang bersangkutan untuk panduan.

Komunitas

  • Mohon jangan hanya "menulis kode". Jika bisa, anda dapat berpartisipasi dalam kegiatan pengembangan lainnya, termasuk: diskusi pengembangan dan dukungan IRC, zzz.i2p dan forum.i2p; pengujian; melaporkan bug dan tanggapan; dokumentasi; ulasan kode; dll.
  • Pengembang aktif harus bisa dihubungi secara berkala di IRC #i2p-dev. Hati-hati dengan siklus rilis saat ini. Patuhi milestone rilis seperti feature freeze, tag freeze, dan checkin deadline untuk rilis.

Siklus Rilis

Siklus normal rilis kami adalah 6-10 minggu. Berikut adalah perkiraan tenggat waktu dalam siklus 8 minggu. Tenggat waktu yang sebenarnya untuk setiap rilis ditetapkan oleh pemimpin pengembang.

  • 1-2 hari setelah rilis sebelumnya: Checkins ke trunk diperbolehkan.
  • 2-3 minggu setelah rilis sebelumnya: tenggat waktu untuk menyebarkan perubahan besar dari cabang lainnya ke trunk.
  • 4-5 minggu sebelum rilis: tenggat waktu untuk permintaan link ke home page baru.
  • 3-4 minggu sebelum rilis: fitur dibekukan. Batas waktu untuk fitur baru.
  • 2-3 minggu sebelum rilis: mengadakan rapat proyek untuk meninjau permintaan link home page baru, jika ada.
  • 7-10 hari sebelum rilis: String dibekukan. Tidak lebih perubahan untuk string yang diterjemahkan ("tagged"). Mendorong string ke Transifex, mengumumkan tenggat waktu terjemahan di Transifex.
  • 7-10 hari sebelum rilis: tenggang waktu fitur. Perbaikan Bug hanya setelah ini Tidak ada fitur tambahan, refactoring atau cleanup.
  • 3-4 hari sebelum rilis: tenggat waktu terjemahan. Tarik terjemahan dari Transifex and periksa.
  • 2-3 hari sebelum rilis: batas waktu check-in. Tidak ada checkins setelah ini tanpa izin dari release builder.
  • Beberapa jam sebelum rilis: tenggang review kode.

Monotone

  • Memiliki pemahaman dasar tentang sistem kontrol kode sumber terdistribusi, bahkan jika anda belum menggunakan Monotone sebelumnya. Ajukan pertanyaan jika diperlukan Setelah didorong, checkin berlaku selamanya, tidak ada revisi. Harap berhati-hati. Jika anda belum pernah menggunakan monotone sebelumnya, mulailah dengan langkah-langkah kecil. Check-in beberapa perubahan kecil dan lihat bagaimana kelanjutannya.
  • Uji perubahan sebelum melakukan checkin. Jika Anda memilih model pengembangan checkin-sebelum-test, gunakan cabang pengembangan anda sendiri (misalnya i2p.i2p.yourname.test) dan sebarkan kembali ke i2p.i2p setelah itu bekerja dengan baik. Jangan rusak build yang sudah ada Jangan membuat regressions. Jika anda melakukan hal ini (sudah terjadi), harap anda jangan kabur untuk jangka waktu yang lama setelah anda mendorong perubahan anda.
  • Jika perubahan anda non-trivial, atau anda ingin orang lain mengujinya dan perlu laporan tes yang bagus untuk mengetahui apakah perubahan anda sudah diuji atau tidak, tambahkan komentar checkin ke history.txt dan buat build revision di RouterVersion.java.
  • Pastikan bahwa anda memiliki file monotonerc yang terbaru di _MTN. Jangan check-in di atas revisi tidak terpercaya.
  • Pastikan anda melakukan 'mnt pull' 'dan 'mtn update' ke revisi terbaru sebelum anda check in dan push. Jika Anda secara tidak sengaja menyimpang, gabungkan dan dorong sesegera mungkin. Jangan sering-sering membuat orang lain menggabungkannya untuk anda. Ya, kami tahu bahwa monotone bilang bahwa anda harus mendorong dan kemudian menggabungkan, tetapi dalam pengalaman kami, penggabungan in-workspace bekerja dengan baik seperti penggabungan dalam database, tanpa membuat revisi penggabungan.
  • Jangan checkin perubahan besar ke dalam cabang utama i2p.i2p di akhir siklus rilis. Jika sebuah proyek memerlukan waktu lebih dari beberapa hari, buat cabang sendiri di monotone dan lakukan pengembangan di sana sehingga anda tidak memblokir rilis.

Gaya Pengkodean

  • Gaya Pengkodean sepanjang sebagian besar kode adalah 4-spasi untuk indentasi. Jangan gunakan tab. Jangan memformat-ulang kode Jika IDE atau editor anda ingin memformat ulang semuanya, kendalikan itu. Ya, kami tahu 4 spasi tidak enak dilakukan, tapi mungkin anda dapat mengkonfigurasi editor anda. Di beberapa tempat, gaya pengkodean berbeda. Gunakan akal sehat. Ikuti gaya ini dalam file yang anda memodifikasi.
  • Semua kelas umum dan paket-pribadi yang baru dan metode memerlukan Javadocs. Tambahkan @since nomor rilis. Javadocs untuk metode privaye baru lebih disukai.
  • Untuk setiap Javadocs yang ditambahkan, harus tidak ada kesalahan doclint atau peringatan apapun. Jalankan 'ant javadoc' dengan Oracle Java 8 atau lebih tinggi untuk memeriksa. Semua parameter harus memiliki baris @param, semua metode non-void harus memiliki garis-garis @return, semua exceptions yang dideklarasikan harus memiliki garis-garis @throws, dan tidak ada kesalahan HTML.
  • Class di core / (i2p.jar) dan beberapa bagian dari i2ptunnel merupakan bagian dari API resmi kami. Ada beberapa plugin out-of-tree dan aplikasi lainnya yang mengandalkan API ini. Berhati-hatilah untuk tidak membuat perubahan yang merusak kompatibilitas. Jangan menambahkan metode ke API kecuali mereka memiliki utilitas umum. Javadocs untuk metode API harus jelas dan lengkap. Jika anda menambahkan atau mengubah API, juga memperbarui dokumentasi pada website (cabang i2p.www).
  • Beri tag kepada string untuk terjemahan di mana tepat. Jangan mengubah string tagged yang ada kecuali benar-benar diperlukan, karena itu akan merusak terjemahan yang ada. Jangan menambahkan atau mengubah tagged string setelah "freeze tag" di siklus rilis sehingga penerjemah memiliki kesempatan untuk memperbarui terjemahan sebelum rilis.
  • Gunakan generik dan concurrent class di mana mungkin digunakan. I2p adalah sebuah aplikasi yang sangat multi-thread.
  • Kenali common pitfalls Java yang tertangkap oleh findbugs. Jlankan 'ant findbugs' untuk mempelajari lebih lanjut.
  • Java 7 diperlukan untuk membangun dan menjalankan I2P. Jangan gunakan Java 8 class atau metode di mana saja. Jangan gunakan Java 7 atau 8 classes atau metode dalam embedded subsystems (inti, router, mstreaming, streaming, i2ptunnel), karena Android dan aplikasi yang dibenamkan memerlukan hanya Java 6. Semua class harus tersedia dalam Android API 9. Fitur Java 7 diterima dalam subsistem ini jika didukung oleh versi Android SDK terbaru dan mereka kompilasi untuk kode Java 6-kompatibel.
  • Secara eksplisit mengkonversi antara tipe primitif dan kelas; jangan bergantung pada autoboxing/unboxing.
  • Jangan gunakan URL. Gunakan URI.
  • Tidak menangkap Exceptions. Tangkap RuntimeException dan exception diperiksa secara satu per satu.
  • Jangan gunakan String.getBytes() tanpa argumen charset UTF-8. Anda juga dapat menggunakan DataHelper.getUTF8() atau DataHelper.getASCII().
  • Selalu menentukan charset UTF-8 saat membaca atau menulis file. Utility DataHelper dapat membantu.
  • Selalu tentukan locale (misalnya Locale.US) ketika menggunakan String.toLowerCase() atau String.toUpperCase(). Jangan gunakan String.equalsIgnoreCase(), karena locale tidak bisa dispesifikasikan.
  • Jangan gunakan String.split(). Gunakan DataHelper.split().
  • Pastikan bahwa InputStreams dan OutputStreams ditutup dalam finally blocks.
  • Gunakan {} untuk semua untuk dan while block, bahkan jika hanya satu baris. Jika anda menggunakan {} untuk blok if, else,atau if-else, gunakannya untuk semua blok. tempatkan "} else {" pada satu baris.
  • tentukan field sebagai final sedapat mungkin.
  • Jangan simpan I2PAppContext, RouterContext, Log, atau referensi lain untuk router atau konteks item di static fields.
  • Jangan mulai threads di dalam constructors. Gunakan I2PAppThread, jangan Thread.

Lisensi

  • Hanya periksa kode yang anda tulis sendiri. Sebelum check in kode atau library jar dari sumber lain, periksa apakah mereka diperlukan, verifikasi lisensi kompatibel, dan dapatkan persetujuan dari pengembang utama.
  • Jika anda memperoleh persetujuan untuk menambahkan kode eksternal atau jar, dan binari tersedia dalam paket Debian atau Ubuntu, anda harus menerapkan opsi build dan packaging dengan menggunakan paket eksternal sebagai gantinya. Daftar Periksa file untuk modifikasi: build.properties, build.xml, debian/control, debian/i2p-router.install, debian/i2p-router.links, debian/rules, sub-build.xml
  • Setiap gambar yang diperiksa dari sumber eksternal, adalah tanggung jawab anda untuk pertama-tama memverifikasi lisensi apakah kompatibel. Termasuk informasi lisensi dan sumber dalam komentar Check-in.

Bug

  • Mengelola Trac tickets adalah tanggung-jawab semua orang, mohon bantuannya. Pantau trac.i2p2.de untuk tiket yang menjadi tanggung-jawab anda atau yang dapat anda bantu. Delegasi, kategorisasi, beri komentar, perbaiki atau tutup tiket, jika anda dapat melakukannya.
  • Pengembang baru harus mulai dengan memperbaiki bug. Cari bug dengan kata kunci 'mudah' di trac. Bila anda sudah memiliki perbaikan, lampirkan patch anda ke tiket dan tambahkan kata kunci 'review-needed'. Jangan tutup tiket telah berhasil ditinjau dan anda sudah memeriksa perubahan. Setelah anda melakukan ini dengan lancar selama dua tiket, anda dapat mengikuti prosedur normal di bawah ini.
  • Tutup tiket ketika menurut anda bug sudah diperbaiki. Kami tidak memiliki departemen tes untuk memverifikasi dan menutup tiket. Jika anda tidak yakin anda telah memperbaiki sebuah bug, tutup dan tambahkan catatan: "Saya pikir saya telah memperbaikinya, silahkan uji dan buka kembali jika bug masih ada". Tambahkan komentar dengan nomor dev atau nomor revisi dan tetapkan milestone untuk rilis berikutnya.