[Gelistirici] kararli depoya paket gecis sureci

[Ekin Meroğlu]

Merhaba;

Tuesday 02 December 2008 tarihinde, Doruk Fisek şunları yazmıştı: 
> Merhaba,
> Seni kiracagima kafami arsiv fareligi yaparim :). Icinde sadece "test"
> kelimesi gecenleri taradim yazdiklarimdan, baska aradan kacanlar olmus
> olabilir.

Eline sağlık ama kırma bi tarafını, gerek yok :-)

> 22 Ekim'de yazdigim e-postada [1] iki farkli oneri yer aliyor. 

Serbülent yazmış - buna uzunca bir cevap vermiştim üzerinde konuşulur diye, 
ama benim uzun postalarım da senin uzun postalarından geri kalmıyor "mark as 
read" işaretlenme konusunda. Aşağıda özetleyeceğim, bunu dışındaki önerilere 
de fikirlerimi yazacağım - bazılarını yazdım daha önce, bazıları yeni. 

> [1] http://liste.pardus.org.tr/gelistirici/2008-October/013904.html
http://liste.pardus.org.tr/gelistirici/2008-October/013908.html

> "Bastan beri soyledigim gibi, test sureci ile kurunun yaninda cok fazla
> yas yakmaya calisiliyor gibime geliyor. Sorun cikarip ortaligin
> karismasina yol acan belli paketler var. Onlari belirleyip, onlarin
> guncellenmesinde testlere ekstra ilgi gosterip, kalanlara sadece temel
> testleri (paket menuye yerlesiyor mu, aciliyor mu) uygulamak daha
> fizibl olur.

Bunun yararı ortada, ama bu listeyi güncel tutmanın pek kolay olmayacağını 
düşünüyorum hala. Üzerimde anlaşılmış ve güncel tutmacıbaşıcısı seçilmiş bir 
liste oluşursa ne güzel - Gönüllü var mı ?  

> Daha da fizibl oldugunu dusundugum soyle bir radikal onerim var :

Bu öneri için ön teknik gereklilikleri özetlemek lazım önce - bunlar karşı 
çıktığım ya da önerdiğim noktalar değil, depo - paket - çiftlik konusunda ön 
bilgi : 

- Birbirinden ikili paket alıp veremeyen her türlü depo eşittir yeni bir 
kaynak depo + yeni bir buildfarm. Şu anki test deposundaki paketler 
bildiğiniz cp komutu ile stable depoya alınıyorlar, çünkü aynı kaynak depodan 
çıkıyorlar. ABI/API yönünden araları açılabilecek iki ayrı ikili paket deposu 
oluşturduğumuz anda  bu yöntem işlemiyor, örn. 2008-stable adlı yeni bir 
kaynak depo ve bu depoyu derleyen bir buildfarm gerekecek. Temel olarak bu 
aynı toolchain'i paylaşan iki dağıtım demek.

- Bu birbirinden ayrı depoların da ayrı birer test ikili deposu olacak : 
stable dal için bu depoya girecek paketlerin test sürecinde bekleyeceği bir 
ara depo, unstable dal için de paketlerin (örn 2 hafta) bekleme ve 
geliştiriciler tarafından test edilme sürecinde bekleyeceği bir ara depo.
   
> 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 :)

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

Bir önceki cevabımın anafikrini oluşturan itirazım işgücü ve seçim yapma 
zorunluluğu üzerineydi, ilk adımda tarif ettiğin stable dala kesinlikle 
ihtiyacımız olduğunu düşünerek o fikrimi daha geniş açıklayayım : 
(1 deposuna stable, 2 deposuna da unstable diyorum)

* X paketinin 4.1 sürümündeyken bu dallanmayı yaptık diyelim. Paketin 4.2, 
4.3, 4.4 sürümleri çıktı, bizim dağıtım için minör olsa da upstream açısından 
hatalar çözüldü, hatta yeni özellikler eklendi - biz de bu paketleri şimdiki 
sistemde de olsa yapacağımız gibi unstable dala aldık, 2'şer hafta test 
deposunda beklettik, olası sorunlarını çözdük. Fakat bu güncellemelerin 
hiçbiri stable dalı için kritik veya güvenlik güncellemesi değildi, 
çıkabilecek regressionlar için getir/götür hesabı yaptık, sonunda stable dala 
almadık : stable 4.1, unstable 4.4'de şu anda.
İşler burada karışıyor  : upstream 4.5 sürümünü iki CVE çözen güvenlik 
güncellemesi olarak yayınladı - sık sık karşımıza gelen senaryo.  
- unstable dal için çok sorun değil , olabiliyorsa 4.4'e backport edilir, ya 
da ters bağımlılık vs sorunu yok ve geçiş güvenlik dışında sadece minor 
değişiklikler içeriyorsa  4.4 -> 4.5 geçişi yapılır, doğrudan depoya alınır 
[şu anda bu süreci uyguluyoruz zaten.] 
- stable dalda ise 4.5 -> 4.1 backportuna ihtiyacımız var : şanslıysak CVE 
yaması işimizi görür, değişikliğin büyüklüğüne ve tipine göre ya test ile ya 
da doğrudan stable depoya hızla alırız. Ama iki deponun arası açıldıkça bu 
süreç daha zorlu olmaya başlar, security ekibininin iki depoyu ayrı ayrı 
gözden geçirmesi gerekir, backport işi her seferinde daha fazla kaynağa 
ihtiyaç duyar, paketlerin daha fazla test edilmesi gerekir. Zorunlu 
kalabileceğimiz sürüm atlamalarında bağımlılıkların da eski sürümde olması 
nedeniyle giderek daha zorlanırız. Security fixlerin gecikmesi bizim camiada 
neredeyse en büyük ayıp sayıldığından, dağıtım eskidikçe security ekibinin 
işi artar, bu sıkışık zamanlar da tahminen bir sonraki sürümün en civcivli 
zamanları olacağından zaman sorunları ortaya çıkar. 

* Unstable deponun giren paket bazında takip edilip zorunlu nezarethane 
sürecini tamamlayan paketlerin hata durumlarının takibi hem bu takibi yapacak 
adama, hem de geliştiriciye daha büyük sorumluluk yüklüyor. 
İlk bölümünü daha yakından tanıyorum : 2007'nin ilk zamanlarında 2 hafta test 
deposunda kalmayan pakete NACK demek benim işimdi, pratikte gerektirdiği 
işgücü ve zamanı ayıramadığım(ız) için uygulayamadığımız bir kural olarak 
tarihe yazıldı. Öbür yanı (geliştirici yanı) ise önyargılı olmak istemememe 
rağmen beni korkutuyor - son bir kaç ayda bugzillada açık hatası olan, 
geliştirici ve kullanıcı listesinde sorunları konuşulmuş paketler bile 
geliştiricilerden / paket sahiplerinden ACK aldı - bunun sebebi önceki 
tartışmalarda genellikle ACK/NACK ve merge süreci olarak ifade edildiyse de 
bence büyük oranda da geliştiricilerin ilgisizliği, zaman zaman yeterli 
bilgi / tecrübeye sahip olmamaları, hatta nadiren bariz inatlaşmaları neden 
oldu bu duruma. Bu cümleler bunu yapamayız demek değil, ama ideal dünyada da 
değiliz - kendi aramızda daha iyi bir test / iletişim / geri dönüş 
mekanizması oturtmalıyız, geliştiricilerin alacağı insiyatif ve 
sorumluluklarının sınırlarını daha iyi belirlemeliyiz demek.
 
Bunlar yapılamayacak /  yetişelemeyecek şeyler mi ? Hayır değil, ama bu 
önerinin sadece bir yeni depo açmak olmadığını söylemeye çalışıyorum - 
tartışırken attığımız adımların neler getireceğini bilerek konuşalım. Bu iki 
depolu yapı gerçekten doğru yol, ama ben şapkayı önüme koyup düşününce ilk 
anda tahmin edilenden çok çok daha fazla kaynak gerektireceğini düşünüyorum. 
Şu anki durumdan sen de ben de memnun değiliz, ama yenisini kurup iki depoya 
da hakettiği ilgiyi gösteremezsek şu anki durumu mumla ararız.

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

Bunu diyebilirsek ne güzel - biz deriz de kim ne kadar anlar emin olamadım :-P

> Ben sistemim kararli kalsin istiyorum
> diyorsaniz, sadece guvenlik guncellemeleri yapilan depoyu kullanin."
> densin. 

> Boylece hedef belirlenmis olur, dagitim depolarinin bir kimligi olur.
> Su anda bence herkes farkli beklentiler icinde dagitimdan ve kimse
> mutlu olamiyor. Hem ultra kararli olayim, hem gelismelerden geri
> kalmayayim, hem o da olsun, hem bu da olsun diye hareket edince hicbiri
> elde edilemiyor.

Burada haklısın, kurumsal kullanıcı için gereken depo kriterleri ile günlük 
kullanıcı - hatta dağıtım fanatiği geliştirici için uyulması gereken 
kriterler farklı, ama şu anda herkes aynı depoyu kullanıyor.

> Bu ilk defa yapilan bisi degil, Debian stable ve testing var. Pardus'un
> surum cikarma dongusunun Debian kadar uzun olmadigi dusunulurse,
> Debian'daki zararli yan etkiler de Pardus'ta cok az olacaktir diye
> dusunuyorum."

Ama bu hamle ile kurumsal kullanıcı / kararlılık arayan kullanıcıyı da anlamlı 
bir şekilde hedeflediğimiz anda onların bir başka önemli isteği olan "uzun 
solukluluk" da bonus olarak geliyor - herhangi bir sürüm için stable dal 
unstable dal'dan daha uzun maintain edilmek durumda kalacaktır doğal olarak.

Debian olmayız tabii ama ortalamayı ve aynı anda sürdürülen dağıtım saysını 
arttıracaktır bu hamle.  

> =======

Geri kalanı ayrı mail.
--
İ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]