[Gelistirici] Test surecleri

[Serbulent UNSAL]

On Sunday 05 October 2008 13:15:38 Ozan Çağlayan wrote:
> Serbulent UNSAL wrote:
> > On Sunday 05 October 2008 10:46:23 Doruk Fisek wrote:
> >> Sun, 5 Oct 2008 06:58:40 +0300, Erkan Tekman <tekman at pardus.org.tr> :
> >>> Burada da şu konuları konuşmak yerinde olacaktır sanırım:
> >>> * Güncel olmak/kalmak ile kararlı olmak/kalmak arasında seçimi hep
> >>> ilkinden yana yapıyoruz. Bu durum gözden geçirilmeli mi?
> >>> * Test süreçleri sürekli olarak yavaşlatıcı bir etken olarak
> >>> görülüyor. Böyle olması kötü mü? Ve/veya daha hızlı olması mümkün mü?
> >>
> >> Bu sorularin kendime gore yanitlarini daha once test sureci ile ilgili
> >> thread'lere birden fazla kere yazdim, yine usenmedigim kadarini
> >> hatirlatayim.
> >>
> >> Test sureci ile ilgili ciddi birkac problem var :
> >>
> >> 1) Test sureci duzenli islemiyor. Guncellenen bir paketin ne kadar
> >> surecek bir surecte "test edilecek" diye askida kalacagi, testin ne
> >> kadar zamanda tamamlanacagi -- hatta teste ne zaman baslanacagi bile
> >> belli degil.
> >>
> >> 2) Gercekten test edilmesi gereken kritik paketler "guvenlik
> >> guncellemesi" diye test edilmeden depoya giriyor.
> >>
> >> 3) Aslinda kirilmasi pek mumkun olmayan, bagimliligi az olan, basit
> >> uygulamalar "test edilmeden aslaa olmaaaaz" diye depoya cok gec giriyor.
> >>
> >> Isin kotusu, her kritik paketi hizli depoya almaktan dolayi problem
> >> ciktiginda "daha yavas guncellenmemiz lazim" diye test surecleri
> >> iyice yavaslatiliyor, kabak problem cikmayan paketlerin basina
> >> patliyor. Kritik paketler yine jet hiziyla depoya giriyor.
> >>
> >> Yani bir Firefox guncellemesini test etmeden depoya aldik diye, bir
> >> oyunun yeni surumu ciktigi gun Pardus'ta guncellenmesine karsin 1-1.5
> >> ay sonra kullanicilara ulasabiliyor.
> >>
> >> Cozum ne?
> >>
> >> 1) Test surecinin "ciddi" yapilmasi. Ornegin her hafta Pazartesi gunu
> >> test surecinin yeni gelen paketler icin tekrar baslanmasi gerekiyor.
> >> Boyle bir insan gucumuz yok deniyorsa -- bunun adi konur, sadece belli
> >> kritik paketlere test sureci uygulanabilir, kalanlar test edilmeden
> >> depoya alinabilir.
> >>
> >> Test edilmeden Pardus deposuna hic paket giremez deniyorsa,
> >> insangucunun yetmedigi kalan paketler contrib deposuna alinmali. En
> >> azindan adam gibi guncellenirler.
> >>
> >> Ama bunun adi mutlaka konmali. Su anda "ne guzel de test yapiyoruz" diye
> >> dusunenler kendilerini kandiriyorlar bence.
> >>
> >> 2) Bir "acil test ekibi"nin olmasi gerekiyor. Yani bir guvenlik
> >> guncellemesi varsa, onu atiyorum 12 saat icinde test edip "tamam, bu
> >> saglam" diyecek birileri olmali. Yanlis anlamayacaginizi umarak
> >> soyluyorum, cekirdek ekipte az sayida insan yok, mesailerinin bir
> >> kismini buna ayirmalari cok zor olmamali.
> >>
> >>
> >> Bir de su anda cok kullanilan uygulamalar kirilmis durumda, 24 saat
> >> gecmesine karsin hala cozum icin bisi yapilmamis durumda. Bu bir tek
> >> bana mi batiyor bilmiyorum. Tatil gunu diyeceksiniz, dogru, o zaman
> >> tatil gununde kritik guncelleme depoya almayalim :/
> >>
> >>                    Doruk
> >
> > Bütün bu söylediklerinin ışığında sadece test süreçlerini değil , kararlı
> > depoya paket alma sürecimizi de baştan tasarlasak diyorum.
> >
> > Önerim şu; Test deposundaki paketinin yeterli kararlılığa ulaştığını
> > düşünen geliştirici listeye ( sanırım en uygunu geliştirici listesi )
> > mail atar ve test isteğinde bulunur. Test sorumlusu bu isteği yakalar ve
> > paket ile ilgili test sürecini işletir[1]. Test sürecinin sonunda ortaya
> > çıkan sonucu listeye gönderir.
>
> Zaten yeterli kararlılıkta olduğunu düşünüyorsa geliştirici niye test
> isteğinde bulunuyor ki bir daha?
>

Test süreci ne halde olduğunu bilmediğimiz paketlerin durumunu görmek için 
değil paketçisi tarafından yeterli kararlılığa ulaştığına kanaat getirilip 
ACK verilen paketlerde gözden kaçan bir sorun var mı ? Paketin kararlı depoya 
geçmesi sistem genelinde bir problem yaratır mı ? vb. sorulara yanıt vermek 
için var. 

Aynı mantıkla şu anki sistemde paketçi ACK vermiş zaten niye test ediyoruz 
dememiz mümkün olurdu.

> Bu kadar "fine-grained" bir mekanizma yüzlerce paket için asla düzgün
> işlemez maalesef.

Ben yüzlerce paketi toplu olarak test etmekle bu şekilde test emek arasında 
bir fark görmüyorum. Eğer çok sıkıştığımızı fark edersek test edilecek 
paketleri sınırlandırır yalnız bizim için önemli olan atıyorum 400 paketi 
test edebiliriz veya başka bir çözüm ararız. Ama böyle bir ihtiyacın olup 
olmayacağını ancak sistemin işleyişi içinde görebiliriz bence.


-- 
İyi Çalışmalar;
 
Serbülent