[Gelistirici] kararli depoya paket gecis sureci

[Ekin Meroğlu]

Merhaba;

Friday 05 December 2008 tarihinde, Erkan Tekman şunları yazmıştı: 

> Yalnızca güvenlik güncellemelerinin yapıldığı bir depo, Ekin'in de
> örneklediği üzere, mor serçenin kuyruğu gibi birşey, ya da ciddi bir
> çiftlik + depo yönetme ve daha önemlisi daha da ciddi bir backport yükünü
> üstlenmek anlamına geliyor. 

Ama bunu doğru yapmamın bence tek yolu - gücümüz yeterse. Yetmiyorsa bölümü 
aşağıda.

> Şu andaki süreç, Doruk'un deyimin ile, "boktan"
> giderken böyle bir yola girmek olsa olsa "bomboktan" bir duruma davetiye
> çıkarmaktır.
> Doruk'un önerisinden benim çıkarabildiğim pratik sonuç şu: Bir "güncel"
> depo olacak, test-mest hakgetire, buraya paldır küldür güncelleme
> yükleyeceğiz. Bir de "güvenlik güncellemesi" deposu olacak, burada yalnızca
> yeni bir güncelleme yaması çıktığında sürüm atlatması (güvenlik yaması
> dahil, aradaki atlamaları da kapsar halde) yapacağız. 

Bu kabul edilebilir bir durum değil : aradaki atlamaları da vereceksek hiç bir 
anlamı kalmadı ki, aradaki her atlamada regression ve bug olasılığı var, 
stable depo olduğunu iddia ettiğin bir depoya 5 sürüm atladıysan yaklaşık 5 
kat riskli bir güncellemeyi sokuyorsun (bilerek abarttım ama amacımı 
anladınız.)

> "Güncel" depo çatlaya 
> patlaya gittiğinden, eğer şansımız yaver gider ise, "güvenlik güncellemesi"
> deposuna yama ekleme zamanı geldiğinde zaten diğer pislikler çözülmüş
> olacak. Kısacası bir test edilen ve bir de test edilmeyen depo olacak...

Ama depodaki atlamaların bir şeyi kırmadığı konusunda o stable depoyu değil 
güncel depoyu kullananların hata raporlarını baz alıyorsun ve yoğun bir  test 
de yapmıyorsun. Yok stable depoda güvenlik güncellemelerini o 5 atlamadaki 
olası tüm regression ve buglara karşı test edelim diyorsan, o zaman da biz o 
güncellemeyi test edip sokana kadar o açık tarih olur, yenisi çıkar hatta :-) 

> Ama bunu şu anda da yapmak mümkün zaten, devel deposu test edilmeyen
> deponun işlevini görüyor. Kararlı depo da hemen hemen (arada bir
> hıçkırmalar dışında) test edilen depo yerine geçiyor. Tek eksik devel
> deposundan ikili bir paket deposu yapmıyor oluşumuz. Evet, biliyorum, biraz
> karikatürize ettim durumu, ama sanırım ana fikri yakaladım.

Hayır, devel deposu bir sonraki sürüme gidiyor - iki hafta sonra devel 
deposundaki X paketlerini 2008 üzerine kuramaz hale geleceksin mesela.. 

Devel burada hiç konuşmamamız gereken bir yerde - şu anda pre-alpha 2009 
seviyesinde örneğin.
 
> Belki çözümler üzerine tartışmak yerine sorunu tarif etsek ve gerekleri
> belirlesek daha yararlı olacaktır.
>
> Bireysel kullanıcı ne ister? Olabildiğince kararlık, buna karşın
> olabildiğince güncel bir sistemle çalışmak. "Kurumsal" (biraz önceki
> bireysel ile aynı depoyu kullanan) kullanıcı ne ister? Ertesi sabah
> sistemini açtığında akşam çalışanların kırılmamasını. Geliştirici ne ister?
> Emek verdiği paketinin en son güncellediği halinin olabildiğince kısa
> sürede depoya girmesini. Sürüm yöneticisi ne ister? Testten geçmemiş
> herhangi bir paketi kullanıcının sistemine yüklememeyi.
 
> Bu gerekleri nasıl birlikte sağlayabiliriz? 

Farklı tip kullanıcıya farklı depo / dağıtım vererek  - ama bu depoları 
gerçekten depo, sürdürülebilir birer dağıtım halinde verebiliyorsak. 
Yoksa "biz de biliyoruz stable depo backport ile yapılır ama adamımız yok, 
biz size sürüm atlayan _kararlı depo_ verelim" dememeliyiz, o zaman o depoyu 
gerçekten vermeyelim. Ama biz böyle bir depo sağlamıyoruz kardeşim diye de 
açık açık söyleyelim.

> Eğer aklımıza ilk gelen yol 
> uygulanabilir ya da gerçekçi değilse B planı ne olur?

Son iki cümlem  B planı oldu galiba..

--
İ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]