Ariya Hidayat wrote: > > 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.
yang beri signal siapa untuk backport ? > > 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? Nah itu DIA permasalahan yang vendor hadapi dan sangat ribet managingnya :-) belum lagi waktu di kompile kan ada fitur yang harus disertakan,beda platform beda masalah (ada device pake ppc ada intel based contohnya)...terus ada fitur yang tidak disertakan.Akhirnya sebagian vendor punya kebijakan, kalau ada major release baru,jangan disuruh customer untuk upgrade ke build tersebut,kecuali "they really have to".. Terus terang kalau masalah ini saya tertarik sekali dan dari hasil diskusi dengan sw lead, saya berikan kepada mereka agar bagian devtest dan bagian dev. menuliskan sebuah 'paragraph' tentang kualitas modul yang ditulisnya , kedua dev/dev.test memberikan rating kepada modulnya,termasuk kemungkinan loophole nya ada dimana,yang untested yang mana,yang low quality dalam kondisi apa ? yang menyebabkan race condition di hal yang mana. Wah ide yang ini saya harus segera PATENkan .. karena proses ini saya yang menemukan dan kasih ide...mumpung belum dicuri orang .. hehehe :-) Carlos
