[Gelistirici] kararli depoya paket gecis sureci

[Ekin Meroğlu]

Merhaba;

Thursday 04 December 2008 tarihinde, Furkan Duman şunları yazmıştı: 
> 02 Aralık 2008 Salı 14:03 tarihinde Doruk Fisek <dfisek at fisek.com.tr> yazdı:
> > Daha da fizibl oldugunu dusundugum soyle bir radikal onerim var :
> >
> > 1) Sadece guvenlik guncellemelerinin yapildigi bir 2008 deposu olsun.
> > Bu depoya giren her guncellemede tirnagina kadar tum yazilimlar testten
> > gecsin. Bu depoya "kararli" olacak densin. Bir paket patlarsa test
> > takimini dovelim :)
>
> Bence radikal değil gerekli bir depo bu. Benim de benzer bir önerim
> olmuştu. Güncel olmak adına zırt pırt sürüm atlatmayalım. Önemli
> hataları ve güvenlik açıklarını çözelim demiştim.

Bu "kararlı depo" için olması gereken durum zaten - ama bu kararlı deponun 
güncel olan karşılığı şu anki test deposu ol(a)mıyor. Güncel bir depo ile 
sıkı kuralları olan kararlı bir depoyu birlikte götürmek için bu ikisinin 
ayrı kaynak depoları olması gerekiyor -  detaylı yazmaya çalıştım daha önceki 
postalarda.
 
> Ancak bu depoya yeni paket girdiğinde bütün depo paketlerinin testi
> bana çok yapılabilir gelmedi. Sonraki başlıkta bahsettiğin gibi,
> sorunlu paketlerin işaretlenip, bunların testinin yapılması yeterli
> sanki. Sadece güncellenen pakete bağımlı paketler de test edilse olur
> gibi.
>
> > 2) Normal depoda test sureci islemesin ya da sadece kritik paketlerde
> > islesin. x hafta test deposunda durup hata raporu almayan paketler
> > normal depoya sorgusuz sualsiz girsin. Kullanicilar "sistemim bozuldu,
> > guncellemeler test edilmiyor mu" dediginde de, "test deposunda x hafta
> > hata belirtilmemis. eger surecin daha iyi olmasini istiyorsaniz, siz de
> > testlere daha cok katilin. Ben sistemim kararli kalsin istiyorum
> > diyorsaniz, sadece guvenlik guncellemeleri yapilan depoyu kullanin."
> > densin.
>
> Adı normal depo olunca kullanıcılardan bunu beklemek haksızlık bence.
> Depo adı "Kararsız depo" olsa söylediğine hak verirdim.
> Depoları çoğaltmaya gerek yok bence. Şu an bir de test depomuz var.
> Bunun yerine bir kararlı bir kararsız depo olsa yeterli sanırım.
> Kararsız depoda bahsettiğin gibi istediğimiz commit i yaparız. Sistem
> bozulursa da "bu kararsız depo idi" deriz. :)

Güncel depo = kararsız depo, bir yere kadar - ama kararsız depo demek önümüze 
geleni kırarız, fena kırılırsa da iki güne düzeltiriz demek olmamalı. 
Ortalama olarak şu anki kararlı depodan biraz daha esnek olabilir bence ama 
daha fazlası kullanıcıları rahatsız etmeye başlayacaktır diye düşünüyorum.
 
> Çoğu kullanıcının, güncellemelerden dolayı kararsız depoyu
> kullanacağını zannediyorum. Dolayısıyla istemeden de olsa test yapmış
> olacaklardır.

Ama test, sonuçları ile ilgili geri dönüş alabildiğimiz sürece anlamlı - 
kullanıcılardan zaman zaman çok değerli geri dönüşler alsak da genel 
ortalamanın pek yüksek olduğunu düşünmüyorum, daha doğrusu geri dönüşlerin 
problemi çözmekte yardımı çok daha az oluyor genellikle.

> > Yanlis anlama, bana uzaktan, merge yapan adam bildigin amelelik yapiyor
> > gibi gozukuyor. Belki sistemin temel bilesenlerinin sik guncellendigi
> > ilk donemlerde, gelistiricileri gemlemek icin iyi bir mekanizmaydi. Su
> > anda anlamsiz bir burokrasiye donusmus durumda. Hem paketini
> > guncelleyen, hem de o paketi merge eden icin."
>
> Katılıyorum. Açıkçası uzun bir süre ayrı kaldıktan sonra geri
> döndüğümde, oluşan bu bürokrasi beni afallatmıştı. Yeni geliştiriciler
> için de korkutucu görünebilir.

Bu merge / farm işinin tabii ki optimize edilebilecek yerleri var, ama  neden 
tek veya sınırlı sayıda geliştirici tarafından işletilmesini tercih ettiğimi 
anlattım sanıyorum.  

> Hem artık bir paket review sürecimiz var. Yeni paketler konusunda
> endişelenmemize gerek olduğunu sanmıyorum.
> Bu review sürecini güncellemelerde de yapmalıyız.  2 onay alan paket
> doğrudan merge edilebilir hale gelebilir. Güncellemeyi yapan de
> kendisi merge eder.

Bu merge'un yapılması sorunu değil, farmı çalıştırıp depoyu oluşturacak 
kişinin bu işleri planlayabilmesi sorunu daha çok.
 
> ACK NACK'i neden yaptığımızı anlamıyorum. Paketimde bir sorun var ise
> zaten depo sorumlusuna haber verip, veya yeni düzenlemede geçersek
> kendim, paketi revert edebilirim. 

İşte senin "haber verme" olarak tanımladığın işi tek yerde - tek seferde 
yapmamın şimdilik bulabildiğimiz yolu bu, niye bu kadar zor geliyor gerçekten 
anlamıyorum. Bu haberleşme tek yerde olmadığı sürece birisi bana 
jabber'dan "şu pakette şu var, almayalım" diyor, bir başkası mail atıyor, bir 
diğeri mail atacaktım unuttum diyor beş gün sonra, beriki "bugzilla'da hatası 
vardı, takip etmiyor musun" diye hesap soruyor. Bunların arşivlenir bir yerde 
tek bir şekilde yapılması gerçekten anlamsız mı ? Diğer türlü test ekibinin 
de , sürüm ekinin de yaptığı teknik işten çok takip ve belgelendirme yapması 
gerekiyor, bunu geliştiricilere yayıyoruz, liste üzerinde herkesin gözü 
önünde takip ediliyor bence. 

Yine söylüyorum, bu en doğrusu değil tabii ki ama bu tip bir işi daha da az 
görünür, daha zor takip edilir bir yola sokmanın neyi düzelteceğini 
anlayamıyorum.    

> Eğer paket test ten geçemediyse ve 
> paketi güncelleyene ulaşılamıyorsa, depo veya bileşen sorumlusu revert
> i yapar. Bunu neden yapıyoruz lütfen birisi söylesin..

- Paketleri ve depoyu takip etmek durumunda olan insanların bunu açık ve 
şeffaf biçimde yapabilmelerini sağlamak,
- açık hatası olup listede hatalı olduğu konuşulmuş bir paketin ACK almasına 
bile rastlanırken "hatalı olan paketi haber versin, hatasını çözene kadar 
revert etsin geliştiricisi" demek bence biraz iyimserlik olduğu için :-)

Derdim yerine koyacağımız yöntem merge/ack hammaliyesini kaldıracak diye 
sevinirken "revert"ler ve "recompile"ler ile daha fazla zaman ve kaynak 
kaybetme ihtimalimiz.
--
İyi Çalışmalar;
Ekin Meroglu <ekin_at_pardus.org.tr>

... did i listen to pop music because i was miserable, or was i miserable
because i listened to pop music?... - rob [nick hornby / hi fi]