> anywa masalah commit ini sebenarnya punya "mazhab" lagi karena > "commit/checkin" punya peran erat dengan kualitas produk dan akhirnya > company revenue/images.
Betul. > - untuk fixing bugs mau di checked in di stable code atau di release khusus ? Mazhab KDE (CMIIW): trunk/main brunch selalu "unstable" (kecuali mau rilis). Jadi bug fix selalu di dimasukkan branch yang dipakai untuk rilis. Lalu, kalau masih ada di trunk, yang di-forwardport. Atau kalau ketemunya di trunk, dibackport ke branch. > kalau di release khusus apakah tiap customer kudu punya special release code > ? > atau sebaiknya semua checked in code dimasukin ke satu image ? Hehe, kalau di dunia open-source semua customernya sama. Jadi ini nggak berlaku. Tapi saya bisa membayangkan version controlnya penuh dengan tag-tag per customer. Wah, mergenya gimana tuh? > - untuk fitur gimana kalo sudah deket deadline ? misalnya mau nambahin > fitur "OSPF LSA Pacing enhancement on ATM-OC3 interfaces with PPP > encapsulation", apa mau codenya dicommit/direlease walaupun ada 20 > showstoppers ? ataukah langsung deliver aja ? (kalo kustomer nemu,baru > disembuhin,etc). Mazhab KDE: beberapa bulan sebelum rilis tidak boleh ada fitur baru. Kalau mau buat fitur baru, harus siap bikin branch dan (di masa depan) merge sendiri nantinya. Dan fitur baru tetap saja tidak akan ikut ke rilis yang sekarang, namanya juga "feature freeze". Optimasi dihitung fitur baru, kecuali super trivial. -- http://www.google.com/search?q=ariya+hidayat&btnI
