[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
Ariya Hidayat wrote: Di vendor,ada aturan sangat ketat untuk check-in code ; Untuk checkin di stable release, gak boleh sembarangan ; harus LULUS Peer code review dulu. Habis itu dilihat lagi,apakah codenya bener2 perlu atau tidak. Hehe, ini lebih relaks dari kebijakan di dunia open-source. Umumnya, asalkan sudah tercompile, kode baru sudah dimasukin ke trunk (main development branch). Jelas untuk branch yang ditujukan jadi versi bugfix (atau service release), kodenya pasti lebih ketat. Juga kalau h ... kalo aturan branching nya ya beda lah,,, kalo peer code review itu dah wajib anytime anywhere . musim bug fixing (setelah feature freeze), semua perlu kena peer review. Untuk KDE, lengkapnya informasinya di sini http://developer.kde.org/policies/commitpolicy.html kalo di open source macam kde gituh yg nentukan check-in atau tidaknya siapa sih ? terus yang bakal code review siapa ? satu orang ? atau dev. lain dalam 1 team ? kalo di vendor, misalnya bikin router... team sw devnya dipecah lagi ke modul2 utama: misalnya routing, mpls , dan system... si routing misalnya punya 4 resources,nah biasanya ada satu team lead disitu,dan team lead itu yang review code temen temenya yang mau commit. IIRC di Microsoft dulunya (info dari Joel on Software), yang memasukkan kode yang membuat aplikasi tidak jalan (compiler error dsb) bertugas jadi babysitter untuk build systemnya, sampai ada yang lain lagi yang membuat kesalahan. Mirip kucing-kucingan. Untuk melihat status keseluruhan, yang saya tahu adalah pakai Mozilla Tinderbox (yang pastinya juga digunakan untuk pengembangan Mozilla). Hampir pasti tool yang lain yang fungsinya sama juga ada. Dan ini memancing pertanyaan selanjutnya: apakah untuk vendor ada message-freeze juga? Kalau untuk KDE (dan pastinya GNOME), ini perlu karena translator harus diberi kesempatan dan cukup waktu untuk menerjemahkan teks dalam program. Tidak bisa hanya detik-detik terakhir. maksudnya run automated test untuk unit testing ? jelas iya. Carlos
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
repost : 8. muhamad carlos patriawan Jan 18, 1:14 pm show options From: muhamad carlos patriawan [EMAIL PROTECTED] - Find messages by this author Date: Wed, 18 Jan 2006 08:14:04 - Local: Wed, Jan 18 2006 1:14 pm Subject: Re: Melacak commits secara real-time Reply | Reply to Author | Forward | Print | Individual Message | Show original | Remove | Report Abuse PS: Kenapa ya kalau pas ada post macam gini biasanya tidak rame? udah pada bosen kali ya :D hehehehehe Hehe, kalau ditanya seperti ini nanti metadiskusi lebih panjang daripada diskusinya sendiri :-) Karena orang yang suka commit gak ada taste kali ... hahahhaa :-) anywa masalah commit ini sebenarnya punya mazhab lagi karena commit/checkin punya peran erat dengan kualitas produk dan akhirnya company revenue/images. Masalah mazhabnya kurang lebih: - untuk fixing bugs mau di checked in di stable code atau di release khusus ? kalau di release khusus apakah tiap customer kudu punya special release code ? atau sebaiknya semua checked in code dimasukin ke satu image ? - 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). Carlos
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
h ... kalo aturan branching nya ya beda lah,,, kalo peer code review itu dah wajib anytime anywhere . Nah, ini menarik. Untuk proyek seperti KDE, kalau peer code tiap kali commit ini terlalu lambat. Jadi hanya kalau bugfix session saja. Aturannya pun dibuat kesepakatan, bergantung si koordinator rilisnya. Contohnya: patch harus dikirim ke milis, dua orang approve, baru boleh check in. kalo di open source macam kde gituh yg nentukan check-in atau tidaknya siapa sih ? Tidak ada. Yang penting bisa dicompile, sudah boleh check in. Karena kontributornya banyak sekali (ratusan) dan tersebar di banyak timezone, sulit kalau masing-masing membuat branchnya sendiri lagi nanti check in kalau sudah stabil. Kalau ragu-ragu, boleh post ke milis biar dibahas sama-sama. Kebanyakan sih no response, jadi berlaku hukum silence means happiness :-P terus yang bakal code review siapa ? satu orang ? atau dev. lain dalam 1 team ? kalo di vendor, misalnya bikin router... team sw devnya dipecah lagi ke modul2 utama: misalnya routing, mpls , dan system... si routing misalnya punya 4 resources,nah biasanya ada satu team lead disitu,dan team lead itu yang review code temen temenya yang mau commit. Sama aja, atau hampir mirip. Untuk core library, biasanya si koordinator rilis (dan kawan-kawan dekatnya) suka memantau commits (lewat #kde-commits di IRC, milis khusus kde-commits, atau svntalk). Kalau ada kode yang kira-kira mencurigakan atau meragukan, tinggal dikontak orangnya. Untuk aplikasi, biasanya ada maintainernya. Kalau ada commit yang tidak setujui maintainernya, tinggal diangkat jadi topik diskusinya. Lagian, biasanya juga orang nggak mengganti aplikasi orang lain secara sembarang. Kalau nggak bisa ditabok (kalau ekstrim, accountnya disuspend), jadi harus permisi dulu, hehe :-) Karena frekuensi commit yang cukup tinggi (seluruh KDE bisa 8000 per bulan), 3-4 bulan sebelum rilis sudah dibuat feature-freeze dan message-freeze. Kalau ada yang mau lanjut bikin fitur baru, silakan saja di trunk (main branch). Tapi rilisnya akan dibuat dari versi yang difreeze itu. Walaupun nggak dipaksa, kalau sudah ada freeze seperti sih mestinya kontributornya ikut cenderung melacak dan memperbaiki bug, membantu si koordinator rilis. maksudnya run automated test untuk unit testing ? jelas iya. Bukan. Maksudnya (message freeze di sini), teks programnya tidak boleh diganti lagi karena translatornya mulai kerja menerjemahkan semuanya. Tentu saja hanya berlaku untuk program yang ada teks yang ditampilkan ke user. -- http://www.google.com/search?q=ariya+hidayat
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
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+hidayatbtnI
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
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
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
wah yang ini lupa: - 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. oh bukan ya.. maksud gue tuh kalu elu sudah checked in fitur diatas , tapi kemudian begitu sudah dekat deadline, kualitasnya buruk... masih ada 10 showstopper misalnya jadi fiturnya gak kerja. gimana pendekatanya kalu di open source ? terus di rilis atau fiturnya di'buang' ? kalo vendor tergantung mazhab,tapi sering dilihat case by case dulu.. Carlos
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
yang beri signal siapa untuk backport ? AFAICS backport selalu sangat dianjurkan oleh si rilis koordinator (setidak-tidaknya, sampai orang yang sekarang). Tinggal bergantung si developer yang membuat patch saja apakah dia mau membackport atau diam saja. Nah itu DIA permasalahan yang vendor hadapi dan sangat ribet managingnya :-) Bisa kebayang. 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.. Dependensi platform ini juga kerja rodi. Ilustrasi yang sering terjadi, mayoritas developer KDE pakai Linux, jadi kadang-kadang ada bagian yang bermasalah dicompile di BSD, AIX atau Solaris. Kalau compile-time masih untung (cepat dicari di mana), kalau run-time lebih puyeng lagi. 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. -- http://www.google.com/search?q=ariya+hidayatbtnI
[teknologia] Re: Kebijakan check-in/commit (was Re: Melacak commits secara real-time)
oh bukan ya.. maksud gue tuh kalu elu sudah checked in fitur diatas , tapi kemudian begitu sudah dekat deadline, kualitasnya buruk... masih ada 10 showstopper misalnya jadi fiturnya gak kerja. gimana pendekatanya kalu di open source ? terus di rilis atau fiturnya di'buang' ? Di KOffice belum pernah mengalami seperti ini, mungkin baru nanti di versi 1.5 yang datang ini :-) IIRC ada pendapat yang kurang lebih the world does not end tomorrow. Jadi kalaupun fitur übercool tapi banyak bug sana sini, mending dipotong saja (simpan di branch, merge di versi berikutnya). Toh akan ada versi selanjutnya. Kalau yang rajin, malah dibuatkan patchnya yang bisa didownload. Jadi bukan bagian dari rilis resmi. Kalau mau pakai, ya compile sendiri dan juga tanggung sendiri hasilnya. -- http://www.google.com/search?q=ariya+hidayat
