[Gelistirici] pisi-svn

[Faik Uygur]

On Paz, 26 Mar 2006, A. Murat Eren wrote:

>  Merhabalar,

Merhaba,

>  Merge etmeye çalışırken çok fazla zaman ve iş gücü gerekeceğini
> düşündüğümden bu yöntem bana biraz imkansız göründü açıkçası :)
> Ayrıca ciddi bugfix'ler oluyor zaman zaman build'de, install'da ya
> da diğer ufak yardımcı modüllerde.  Ayrı ayrı kişiler tarafından da
> yapılabilen bu fixlerin sürekli diğerleri tarafından kendi
> branch'larına merge edilmesi gerekliliği gibi bir sorun da meydana
> çıkabilir gibi geliyor bana şu an bu senaryoda.

Bence de endişelerinde haklısın. Ama herkesin kendisine ait bir
repository'si olsun gibi bir görüşde de değildim. Development trunk'da
devam etmeli kesinlikle. Tüm bugfixler de zaten trunk'da mevcut. Sadece 
uzun süreli olacağı ve bu sürede trunk ile çalışacakları engelleyeceği 
düşünülen _iş_, ayrı bir yerde yapılıp trunk'a merge edilebilir. Bu iş 
bitince zaten yine herkes trunk'da çalışıyor. Bu iş bir feature olabilir 
ya da bugfix olabilir.

>  Dediğin gibi sorunsuz çalışma için bir çözüm, sık sık en azından
> yarı stable release'ler çıkarmak ve devel ile hiç çalışmamak
> olabilir. Fakat o zaman da PiSi'nin devel branch'i nasıl bu stable
> sayılır denecek kadar test edilecek?

_Yarı stable_ release'ler belki Çağlar'ın işine yarayabilir. Burada da
dediğin gibi stabilitesinin kararı konusu sorun. Elbette devel'de
hatalar çıkacaktır.  Ama buradaki stabilite de, aslında pisi şu
haliyle çalışıyor, kullanılabilir anlamında olabilir herhalde. Yani
devel'in bilinen son _çalışılabilir_ noktaları.  Yine hatalar çıkabilir 
tabii ki. Ancak ben aldığım zaman örneğin bir pisi it ile hata almamalıyım.

devel'i kullananın dışında, bir de geliştirici'yi düşünürsek. Install
akışında ve ya build akışında bir hatayı reproduce edip düzeltmesi
gerekiyor. Ama devel'in son halinde install dağılmış durumda ve
çalışmıyor. Bu duruma da bir çare bulunması gerekiyor gibi geliyor. 

>  Bunun bir yolu test driven gitmek olabilir. Sürekli unittest'leri
> güncellemek ve eskilerinin doğru şekilde çalıştığından emin olarak
> gitmek şeklinde.

Yazacağım bir feature'ın önce unittest'ini yazıp dediğin gibi
feature'ın fonksiyonel kısımlarının çalıştığından emin olup adım adım
ilerleyebilirim. Tüm unittestleri çalıştırıp hepsinin çalıştığına emin
oldukça commit edebilirim. Ama bu da ne kadar uygulanabilir
bilemiyorum. Geliştirme esnasında unittestlerin çoğu fail olabilir. O
zaman commit etme diyeceksin :) Ama uzun bir iş bu. O an eklediğim bir
feature'ı bir hafta boyunca çalışana kadar commit etmeyip diskimde de
tutmak istemiyorum. Adım adım kendi içinde bütünlüğü olan kısımlarını
commit edebilmek istiyorum.

>  Bence bizim sorunumuzun çözümü kesinlikle unittest'leri sıkı
> tutmaktan geçiyor.

Bilemiyorum ki meren kardeş, bir orta yol bulsak. :)

Görüşmek üzere, 
- Faik