[Gelistirici] kararli depoya paket gecis sureci

[Furkan Duman]

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.

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. :)

Ç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.


> 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.

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.


> Zaten paketci "ACK" vermeden once paket bir sure test deposunda
> geciriyor. Bu prosedurle bir paketin kararli depoya girmesi bir aydan
> bile fazla surebilir.

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. 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..

-- 
Furkan Duman